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PREFACE 


The  methods  detailed  in  this  document  have  provided  the  Initial  Graphics  Exchange  Spec- 
ification (IGES)  community  with  advanced  visibility  of  the  changes  approved  by  the  vol- 
untary organization  responsible  for  the  IGES  Standard.  Through  this  process,  each 
technical  change  reaches  consensus  separately,  and  is  held  for  incorporation  into  the  sub- 
sequent version  of  IGES.  These  methods  were  adapted  from  tne  aerospace  “engineering 
change  proposal  and  change  order”  process.  The  process  is  still  being  improved  through 
the  use  of  hypertext  on  the  Internet,  thereby  providing  the  organization  with  a timely 
response  to  proposals  for  extensions  and  repairs  needed  by  implementors  and  users  of 
IGES. 

The  implementation  details  of  the  process  have  evolved  over  the  years,  and  now  embody  a 
complete  life  cycle  system  of  electronic  procedures.  These  procedures  involve  the  IATEX 
publishing  language,  Internet  submission/notification,  and  hypertext  on-line  information 

database1  that  is  availability  during  IGES  Organization  meetings.  The  database  includes 
an  index  of  all  changes  formally  approved,  from  the  initial  use  of  the  process  in  1981  to 
the  present.  All  the  database  files  may  be  searched  to  identify  prior  changes  as  well  as  the 
present  status  of  each  proposed  change.  The  process  additionally  provides  an  audit  trail  for 
the  consensus  and  quality  checks,  in  both  electronic  and  paper  form,  for  each  version  and 
for  each  proposed  technical  change. 

The  process  for  integrating  the  approved  changes  electronically  into  the  files  constituting 
the  “next  version  of  IGES”  was  developed  by  Dr.  Philip  Kennicott  of  Sandia  National 
Laboratories.  The  integration  process  enabled  the  use  of  the  Internet  for  dealing  with 
changes  that  were  inherently  in  electronic  form.  This  integration  provided  the  means  for 
placing  approved  changes  directly  into  the  Standard  without  re-entry  (and  possible  errors) 
during  production  of  an  IGES  version. 

Examples  of  the  use  of  the  Internet  include  an  automated  distribution  of  Request  for 
Change  (RFC)  documents,  and  World  Wide  Web  access  to  RFC  documents  in-work  by 
committee  (http://www.eeel.nist.gov/iges)  and  the  Edit  Change  Orders  that  constitute  the 
next  version  of  IGES  (http://www.eeel.nist.gov/iges/ecoList.html).  Each  are  updated  fol- 
lowing each  IGES  Project  meeting. 

Lastly,  the  authors  developed  the  process  for  recording  the  committee  actions  and  project 
consensus  in  the  hypertext-files  environment.  Taken  together  and  detailed  in  this  docu- 
ment, the  process  documents  the  complete  life  cycle  in  an  open  environment. 


1.  The  examples  of  the  change  process  forms  which  appeared  in  appendices  of  the  previous  edition  of  this 
document  (dated  March  1,  1993)  have  been  published  in  C.  Parks,  “Applying  Hypertext  to  Managing 
Versions  of  a Standard,”  September  1993,  NISTTR  5245;  available  from  the  IGES/PDES  Office,  NIST, 
Bldg  220,  Rm.  A- 127,  Gaithersburg,  MD  20899. 
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Preface  Illustration. 

The  process  for  changes  to  IGES  adopts  the  change  management  followed  by  industry. 
Industry  configuration  management  process  provides  continuous  product  quality 
improvement  over  production  runs.  The  result  is  timely  response  to  technical  change 
requests  needed  by  the  IGES  community.  The  adopted  change  management  practice  is 
augmented  by  the  publishing  business  practice  of  proofing  prior  to  printing  each  version 
of  the  Standard. 
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1.0  Introduction 

The  purpose  of  this  document  is  to  provide  a record  of  the  underlying  rationale  and  the  detailed 
procedures  by  which  the  initial  Graphics  Exchange  Specification  (IGES)  is  changed,  new  versions 
are  approved,  and  the  document  itself  is  edited,  maintained,  and  published  by  the  IGES  Project  of 
the  IGES/PDES  Organization  (IPO). 

It  is  intended  that  the  Initial  Graphics  Exchange  Specification  continue  to  be  submitted  to  and 
approved  by  the  American  National  Standards  Institute  (ANSI)  as  a voluntary  American  National 
Standard. 

This  document  also  defines  the  life-cycle  documentation  supporting  these  activities  and  provides 
guidance  for  its  use,  including  record  keeping  requirements,  to  provide  evidence  of  compliance 
with  these  procedures.  These  records  include  Request  for  Change  (RFC),  Edit  Change  Order 
(ECO),  and  ballot  results  and  comments. 

Procedures  given  in  this  document  are  intended  to  be  supplementary  to  and  consistent  with  the 
documented  procedures  of  the  General  Assembly  of  the  IPO  for  the  IGES  Project.  In  general,  pro- 
cedures in  this  document  are  at  a more  detailed,  working  level.  A function  model  is  provided  in 
Appendix  A. 

Several  list  formats  are  used  in  this  document.  Numbered  lists  indicate  ordered  items,  bulleted 
lists  indicate  unordered  items,  ^-marked  lists  indicate  recorded  items,  and  ^ -marked  lists  indi- 
cate required  action  items. 

1.1  Due  Process  and  Consensus 

The  primary  conditions  to  be  satisfied  in  changing  and  approving  new  versions  of  the  Specifica- 
tion concern  due  process  and  consensus.  Adherence  to  these  procedures  will  result  in  the  condi- 
tions for  due  process  and  consensus  being  met  as  new  versions  of  IGES  are  developed  and 
approved  within  the  IGES  Project  of  the  IPO. 

Due  process  means  that  any  person  (organization,  company,  government  agency,  individual,  etc.) 
with  a direct  and  material  interest  in  the  Specification  has  a right  to  participate  once  membership 
requirements  are  met  by  expressing  a position  and  its  basis,  having  that  position  considered,  and 
appealing  if  adversely  affected.  Due  process  results  in  requirements  that  must  be  satisfied  in 
developing  consensus  such  as  openness  (participation  open  to  all  persons  directly  and  materially 
affected),  balance  (no  domination  by  any  single  interest  category),  and  prompt,  thorough  consid- 
eration of  written  views  and  objections,  with  a concerted  effort  being  made  toward  their  resolu- 
tion. 

Consensus  means  that  “substantial  agreement”  is  achieved  among  those  persons  who  are: 

• affected  by  the  matter  at  hand, 

• entitled  to  determine  its  outcome,  and 

• participants  in  the  decision  process. 

In  this  procedure,  substantial  agreement  resulting  in  consensus  can  be  obtained  only  after  credible 
minority  positions  have  been  reconciled  with  the  majority.  (Section  5.0  outlines  appeal  proce- 
dures covering  situations  in  which  a minority  position  is  unable  to  be  reconciled.) 
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1.2  General  Operating  Policies  for  IGES  Committees 

For  the  purposes  of  this  document,  IGES  committees  include  the  IGES  Project  Committee,  IPO 
Technical  Committees  involved  in  work  to  change  and  approve  new  versions  of  the  Specification, 
and  committees  established  within  the  IGES  Project  of  the  IPO  at  the  discretion  of  the  Project 
Manager  (such  as  the  Gray  Page  Committee). 

IGES  Committees  typically  meet  at  IPO  meetings.  Specifics  of  upcoming  meetings1,  including 
preliminary  agenda,  are  contained  in  the  Meeting  Announcement  mailed  to  IPO  members  prior  to 
each  meeting.  Interim  meetings  of  the  IGES  Project  and  of  IGES  Technical  Committees  may  be 
convened  as  necessary.  Interim  meeting  announcements  shall  also  include  an  agenda.  Decisions 
about  agenda  items  that  are  made  at  interim  meetings  shall  have  the  same  authority  as  decisions 
made  at  IPO  meetings;  decisions  concerning  “non-agenda”  items  of  a non-trivial  nature  shall  be 
deferred  to  the  next  meeting  unless 

• the  item  is  urgent,  and 

• the  number  of  attendees  voting  for  approval  is  equal  to  or  greater  than  a majority  of  the 
total  committee  membership  of  record. 

Committee  members  who  cannot  attend  any  announced  meeting  may  vote  or  comment  on  an 
agenda  item  by  writing  to  the  committee  chairperson. 

Minutes  will  be  recorded  for  each  official  meeting  of  an  IGES  committee  and  will  be  made  avail- 
able to  any  interested  person.  At  an  official  meeting,  minutes  of  the  previous  meeting  will  be 
approved  by  vote.  Minutes  shall  include  sufficient  detail  to  enable  those  familiar  with  the  work  of 
the  committee  to  understand  the  business  conducted. 

Minimum  requirements  shall  include: 

a list  of  attendees 

text  of  motions  and  names  of  all  members  making  and  seconding  them 
results  of  all  votes  taken 

identification  of  all  actions  taken  by  acclamation. 

In  addition,  for  each  RFC  discussed,  the  RFC  number  and  a summary  of  key  discussion  points, 
including  names  of  participating  members,  should  be  included.  Refer  to  Guidelines  For  Preparing 
Meeting  Summaries  in  The  Handbook  For  Chairs  of  IPO  Technical  Committees  And  Interest 
Groups. 

At  any  duly  called  meeting  of  an  IGES  Committee,  the  agenda  is  left  to  the  discretion  of  the 
Chairperson,  since  the  topics  to  be  discussed  may  depend  on  qualified  persons  being  present.  A 
vote  always  shall  be  taken  on  technical  matters,  and  consensus  is  required.  Either  a vote  or  accla- 
mation may  be  used  for  administrative  matters,  and  consensus  is  not  required.  All  actions  shall  be 
recorded  in  the  minutes,  including  names  of  persons  making  and  seconding  motions  when  used, 
as  well  as  key  discussion  points  to  document  the  reasons  for  the  action  taken. 

Anyone  with  voting  membership  status  in  the  General  Assembly  of  the  IPO  may  vote  in  any 
Technical  Committee  on  any  IGES  matter.  Membership  in  the  IGES  Project  Committee  is  com- 


1.  Meeting  announcements  and  registration  information  are  mailed  prior  to  each  meeting;  contact  USPro, 
(703)  698-9606  or  see  World  Wide  Web  page  at  http://elib.cme.nist.gov/nipde/. 
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prised  of  the  IGES  Project  Manager,  the  Deputy  Project  Manager,  the  Chairperson  of  every  IPO 
Technical  Committee  involved  in  the  project,  the  IGES  Editor,  the  IGES  Ballot  Coordinator,  the 
Change  Control  Secretary,  the  heads  of  IGES  Project  Subcommittees,  and  others  at  the  discretion 
of  the  IGES  Project  Manager.  A Technical  Committee  is  “involved”  if  its  scope  of  work  as 
described  in  the  Handbook  (mentioned  above)  explicitly  mentions  IGES-related  work.  [Refer  to 
IGES/PDES  Organization  Reference  Manual  (available  from  the  IPO  Office  or  at  IPO  meetings), 
for  more  information.] 

In  many  instances  in  this  document,  the  reference  is  made  to  Chairperson  of  the  custodian  com- 
mittee, meaning  the  Chairperson  of  the  relevant  Technical  Committee  of  the  IPO  General  Assem- 
bly. In  these  instances,  “Chairperson”  can  be  interpreted  to  mean  “Chairperson  or  appropriate 
designee.”  For  several  Technical  Committees,  the  Deputy  Chairperson  has  been  given  responsi- 
bility for  cc  -dination  with  ' e IGES  Project  Committee. 

2.0  The  Initial  Graphics  Exchange  Specification 

The  Initial  Graphics  Exchange  Specification  defines  a non-proprietary  format  for  CAD  system 
data.  The  format  is  used  primarily  for  the  exchange  of  data  between  different  CAD  systems.  The 
fundamental  unit  of  IGES  data  is  an  IGES  entity  type  instance.  The  fundamental  unit  of  commu- 
nication of  IGES  data  is  an  IGES  file.  The  Specification  therefore  consists  primarily  of  a collec- 
tion of  entity  type  definitions  together  with  instructions  for  assembling  a valid  IGES  file.  “The 
Specification”  refers  to  a document  including  several  appendices.  The  main  body  of  the  document 
contains  the  official  portion.  The  appendices  are  normally  not  part  of  the  official  portion. 

Software  units  generally  termed  “processors”  are  used  to  read  and  write  IGES  data.  “Pre-proces- 
sors” write  IGES  data,  and  “post-processors”  read  IGES  data.  The  term  “translator”  also  is  used 
when  the  conversion  operation  between  the  IGES  data  and  CAD  system  data  is  to  be  emphasized. 

Changes  to  the  Specification  may  vary  from  a simple  language  clarification  to  a fundamental 
extension  such  as  the  addition  of  a new  entity  type.  Extensions  to  the  Specification  occur  prima- 
rily in  response  to  new  requirements  identified  by  its  users.  Changes  and  extensions  are  subject  to 
an  IGES  Project  policy  termed  “Gray  Pages.”  Changes  and  extensions  subject  to  this  policy  are 
released  from  the  Gray  Page  designation  when  tested  and  found  suitable  for  general  use. 

2.1  The  Role  of  the  Specification 

The  Specification  should  be  able  to  codify  CAD  system  data  accurately  and  completely  for  the 
purposes  of  successful  exchange  with  other  CAD  systems,  archiving,  and  sharing  with  other 
applications.  Due  to  the  diversity  of  the  systems  involved,  perfect  results  under  all  circumstances 
are  unlikely;  however,  it  is  intended  that  coverage  of  the  CAD  system  data  should  be  as  complete 
as  is  practical. 

Many  types  of  entities  are  defined  in  the  Specification,  and  may  be  used  individually  or  collec- 
tively in  order  to  accept  the  CAD  data.  There  is  a great  amount  of  flexibility  built  into  the  Specifi- 
cation for  accomplishing  this.  For  example,  the  Associativity  entity  type  provides  flexibility  for 
collective  use  of  entities,  and  the  Property  entity  type  provides  flexibility  for  modifying  or  provid- 
ing additional  information  concerning  another  entity.  The  meaning  of  certain  forms  of  these  entity 
types  is  defined  in  the  Specification,  while  for  other  forms,  the  meaning  can  be  tailored  to  the  indi- 
vidual situation  and  specified  in  the  file  itself. 
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Careful  choices  must  be  made  to  ensure  that  the  IGES  entities  used  faithfully  represent  the  impor- 
tant characteristics  of  the  CAD  system  data  (e.g.,  the  visual,  geometric,  functional,  and  associa- 
tive characteristics).  Full  usage  of  the  flexibility  of  the  Specification  in  representing  data  can 
maximize  the  potential  for  complete  exchange  results,  but  it  must  be  emphasized  that  more  com- 
plex entities  should  not  be  used  when  simpler  entities  are  sufficient. 


2.2  Changes  to  the  Specification 


Technical  changes  to  the  Specification  are  approved  via  a ballot  process.  The  Request  For  Change 
(RFC)  is  the  formal  mechanism  by  which  changes  are  proposed  and  balloted.  Editorial  changes  to 
the  Specification  may  be  initiated  by  the  IGES  Project  Committee  without  an  RFC.  In  either  case, 
the  Edit  Change  Order  (ECO)  is  the  formal  mechanism  by  which  the  IGES  Editor  is 

• informed  of  the  content  of  a change  to  the  Specification  (either  main  body  or  appendices), 
and 

• authorized  to  make  the  change  to  the  master  copy  of  the  Specification. 


Figure  1 illustrates  the  major  processes  for  changing  and  maintaining  the  Specification. 


New  RFC 


Figure  1 . The  Major  Processes  for  Changing  and  Maintaining  the  Specification 


Changes  are  divided  into  three  types: 

• Editorial:  approval  of  the  proposed  change  by  the  IGES  Project  Committee  results  in  an 
ECO  to  direct  the  IGES  Editor  to  change  the  Specification 

• Clarifications  or  fixes:  approval  of  the  RFC  from  the  ballot  process  means  that  the  RFC 
content  will  become  part  of  the  main  body  of  the  Specification  (subject  to  editorial  harmo- 
nization) 

• Extensions:  approval  of  the  RFC  from  the  ballot  process  signifies  approval  of  the  concept 
involved,  but  the  RFC  content  will  become  part  of  the  Untested  Entities  Appendix  (“Gray 
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Pages”)  until  satisfactorily  tested. 

Editorial  changes  proposed  are  intended  to  correct  misspellings,  grammar  problems,  inconsistent 
style,  etc.,  to  repair  errors  in  updating  the  Specification,  and  to  improve  utility  of  the  document. 
Editorial  changes  do  not  require  an  RPC  nor  a mail  ballot  because  they  do  not  alter  the  intent  of 
the  portion  of  the  Specification  they  affect. 

Clarifications  or  fixes  to  “refine”  the  Specification  are  encouraged,  because  one  goal  is  that  the 
Specification  be  written  clearly  and  succinctly  to  ensure  consistent  interpretation.  Consistent 
interpretability  should  not  depend  upon  the  reader's  attendance  at  IPO  meetings.  This  category  of 
change  is  distinguished  from  the  “Editorial”  category  by  its  alteration  of  the  intent  of  the  portion 
of  the  Specification  affected  (e.g.,  adding  a sentence  to  cross-reference  related  information  is  edi- 
torial— RFC  not  required;  adding  a sentence  to  specify  entity  usage  is  clarification — RFC 
required).  This  category  also  includes  changing  the  Specification  to  “deprecate”  an  entity  by  mov- 
ing it  from  the  main  body  of  the  Specification  to  the  Obsolete  Entities  Appendix;  although  such 
entities  remain  valid,  new  uses  of  them  are  not  recommended. 

Extensions  generally  involve  adding  new  capabilities  or  making  fundamental  changes  to  the 
Specification  (e.g.,  the  addition  of  a new  entity  type  or  the  addition  of  a new  form  of  an  existing 
entity).  Most  extensions  must  be  tested  to  ensure  they  can  be  implemented  correctly  before  they 
can  become  part  of  the  main  body  of  the  Specification;  this  is  called  “Gray  Page”  testing  and  must 
include  successful  exchanges  involving  at  least  three  processor  implementations.  See  Section  3.4 
for  more  information  concerning  the  Gray  Page  process.  At  the  IGES  Project  Committee's  discre- 
tion, Gray  Page  testing  may  be  omitted  for  “functional”  extensions  of  mechanisms  already  proven 
in  commercially  available  IGES  processors  (e.g.,  adding  a new  attribute  to  an  existing  attribute 
table  entity,  adding  new  text  or  line  fonts)  because  the  only  result  would  be  to  identify  that  imple- 
mentation actually  occurred.  Given  the  large  number  of  existing  untested  entities  to  be  tested, 
such  a diversion  of  limited  testing  resources  cannot  be  justified  for  so  little  value.  Furthermore, 
since  the  decision  to  test  also  is  balloted,  anyone  objecting  to  omission  of  testing  may  cast  a dis- 
approval vote. 

2.3  Constraints  for  Changes  to  the  Specification 

A principal  constraint  regarding  changes  to  the  Specification  has  to  do  with  upward  compatibility. 
Upward  compatibility  is  interpreted  to  mean  that  “old”  files,  i.e.,  files  valid  with  respect  to  earlier 
versions  of  the  Specification,  should  remain  valid  with  respect  to  later  versions  of  the  Specifica- 
tion. The  benefits  of  upward  compatibility  are  that  processors  based  on  later  versions  of  the  Spec- 
ification are  able  to  accept  files  produced  by  processors  based  on  an  earlier  version  and  that 
archived  files  will  not  become  obsolete. 

Upward-incompatible  changes  generally  will  not  be  allowed  unless  there  is  a clear  case  where  the 
best  interests  of  users  of  the  Specification  are  served  by  approving  them  (e.g.,  the  Specification 
may  need  to  be  tightened  technically  because  what  is  allowed  currently  is  counterproductive — 
this  happened  with  the  Conic  Arc  entity).  A factor  in  considering  upward-incompatible  changes  is 
the  state  of  processor  implementations  as  best  they  can  be  determined.  In  theory,  adverse  effects 
from  upward-incompatible  changes  would  be  minimized  if  processors  used  the  Global  Section 
version  number  properly  because  it  identifies  if  a file  was  created  before  or  after  the  upward- 
incompatible  change.  In  practice,  this  technique  can  fail  because  pre-processors  may  specify  a 
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later  version  number  for  a reason  other  than  making  the  upward-incompatible  change(s)  required 
for  that  version. 

Downward  compatibility  is  interpreted  to  mean  that  processors  based  on  earlier  versions  of  the 
Specification  are  able  to  accept  files  produced  by  processors  based  on  a later  version  because  their 
robust  design  deals  “gracefully”  with  extra  data  they  do  not  understand.  However,  they  cannot 
reasonably  be  expected  to  accept  correctly  files  containing  upward-incompatible  changes  because 
they  will  not  be  aware  of  them.  Downward-incompatible  changes  generally  are  allowed;  often 
they  are  unavoidable.  However,  to  minimize  costly  interoperability  problems,  all  changes  to  the 
Specification  should  be  designed  for  as  much  version  compatibility  as  is  practical. 

3.0  The  Processes  for  Approving  Changes  to  the  Specification 

Technical  changes  to  the  Specification  are  formally  proposed,  considered,  and  balloted  by  means 
of  the  Request  for  Change  (RFC)  process.  Editorial  corrections  (e.g.,  typographical  errors)  may 
be  handled  by  notifying  the  IGES  Editorial  Committee  without  using  the  formal  RFC  process. 

An  RFC  which  ultimately  results  in  a technical  change  to  the  Specification  may  involve  the  gener- 
ation and  retention  of  a considerable  amount  of  information  over  a period  of  time;  however,  the 
initial  stages  of  originating  and  proposing  an  RFC  purposely  are  kept  simple  to  encourage  poten- 
tial RFC  authors. 

RFCs  are  administered  by  the  IGES  Project  Committee.  The  work  to  take  a potential  RFC  from 
concept  to  completion  is  coordinated  by  a technical  committee  (e.g.,  Drafting)  designated  as  cus- 
todian. 

RFCs  are  balloted  within  the  IPO  General  Assembly  after  approval  by  custodian  committee(s) 
and  the  IGES  Project  Committee.  An  RFC’s  problem  statement  and  proposed  solution  should 
demonstrate  the  author  has  1)  identified  all  implications  of  the  proposed  change  to  the  Specifica- 
tion, and  2)  prepared  a clear,  succinctly  written  proposal.  Past  experience  reinforces  the  need  to 
do  a complete,  high-quality  job  initially,  otherwise,  considerable  time  and  effort  will  be  expended 
during  revisions  that  result  from  the  balloting  process. 

A later  section  explains  more  informal  ways  of  presenting  IGES-related  ideas,  issues,  questions, 
etc.,  to  the  IPO  General  Assembly  membership  for  their  written  comments. 

3.1  The  Parts  of  a Request  for  Change  (RFC) 

A complete  RFC  consists  of  three  parts:  an  RFC  Cover  Sheet,  an  RFC  Form,  and  an  RFC  Folder. 
Each  of  these  parts  evolves  as  the  RFC  traverses  the  various  coordination  processes. 

The  RFC  Form  is  the  heart  of  the  complete  RFC.  It  originates  with  the  RFC  author  and  encom- 
passes the  technical  details  of  the  proposed  change.  The  RFC  Form  is  circulated  as  necessary.  All 
technical  deliberations  are  made  on  the  basis  of  the  content  of  the  RFC  Form.  RFC  ballots  are  cast 
against  the  content  of  the  RFC  Form.  The  RFC  Form  includes  limited  administrative  information 
which  is  either  required  for  managing  associated  processes  or  considered  to  be  relevant  general 
information. 

The  RFC  Cover  Sheet  is  an  administrative  tool  originating  with  the  IGES  Change  Control  Secre- 
tary. It  is  used  to  record  all  official  business  transactions  that  unfold  concerning  a particular  pro- 
posed change  (e.g.,  Form  log-in  date,  Technical  Committee  decisions,  IGES  Project  Committee 
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approvals).  The  Cover  Sheet  is  tied  to  the  RPC  Form  but  is  not  as  widely  circulated  as  the  Form. 
Responsibility  for  the  Cover  Sheet  begins  with  the  Change  Control  Secretary,  then  responsibility 
changes  for  various  entries  through  the  RFC  process. 

The  RFC  Folder  originates  with  the  custodian  committee.  It  is  an  open-ended  storage  device  for 
technical  records  pertaining  to  the  RFC,  such  as  ballot  comments  made  on  the  RFC  and  associ- 
ated records  for  custodian  committee  resolution  of  these  comments.  The  RFC  Folder  rerr  is  with 
the  custodian  committee. 

See  Appendix  B,  Example  of  Cover  Sheet  Forms.  The  blank  RFC  Cover  Sheet  may  use  out  is 
not  initially  required;  the  RFC  may  initially  be  in  any  legible  format.  The  author  is  encouraged  to 
create  the  electronic  form  of  the  RFC  as  soon  in  the  process  as  possible,  and  prior  to  assigning  a 

tracking  number.  The  “skeleton  file”  for  use2  with  any  text  editor  together  with  its  README  file 
may  be  obtained  from  IGES  Project  Officers  or  through  a link  displayed  on  a World  Wide  Web 
page  (http://www.eeel.nist.gov/iges/igesTools.htnil).  Section  3.2  documents  the  meaning  and 
collection  of  the  data. 

RFCs  accepted  into  the  coordination  process  are  numbered  sequentially.  Sequential  “issue”  ver- 
sions (“A,”  “B,”  “C,”  etc.;  where  “A”  is  the  first  revision)  of  each  RFC  may  exist  to  track  changes 
introduced  during  the  coordination  process. 

All  RFCs  will  exist  officially  as  paper  documents.  RFC  Cover  Sheets  and  RFC  Forms  will  be 
archived  by  the  Change  Control  Secretary  as  paper  documents.  All  issue  versions  will  be  archived 
as  separate  documents. 

Ultimately,  the  master  copy  of  the  RFC  Form  will  exist  and  be  maintained  in  electronic  form  (cur- 
rently the  IATeX  format,  which  is  basically  ASCII  text).  Further  details  appear  later  in  this  section. 

3.2  The  Technical  Coordination  Process 

This  section  defines  the  process  by  which  new  RFCs  are  received,  logged,  assigned  to  a custodian 
committee  for  technical  coordination  and  approval,  and  prepared  for  ballot. 

3.2.1  Origination  of  a New  RFC 

Anyone  may  propose  a change  to  the  Specification,  but  it  should  be  kept  in  mind  that  an  RFC  is 
intended  to  document  both  the  need  to  make  a change,  and  a carefully  prepared  proposal  to 
accomplish  that  change.  Problems  without  apparent  solutions  or  with  incomplete  solutions  should 
be  addressed  initially  by  one  of  the  other  methods.  Possible  methods  are  suggested  in  Section  7 
identifying  another  way  to  deal  with  the  problem,  or  confirming  the  need  to  create  an  RFC  using 
suggestions  of  others  to  formulate  the  proposed  solution. 

Consideration  of  a proposed  change  is  initiated  by  furnishing  the  IGES  Change  Control  Secretary 
with  a technical  description  of  the  proposed  change  in  the  form  of  a new  RFC.  A new  RFC  must 
contain  the  minimum  information  and  structure  listed  below  before  the  secretary  will  assign  a 
number;  however,  most  authors  supply  a “first  draft”  of  the  complete  RFC.  New  RFCs  supplied  to 
the  Change  Control  Secretary  must  be  in  paper  form',  preparing  the  electronic  form  at  this  stage  is 

2.  The  details  of  editing  in  IATgX  are  beyond  the  scope  of  this  document;  the  RFC  author  is  encouraged  to 
seek  documents  on  the  subject,  such  as  L.  Lamport,  lATgXA  Document  Preparation  System , 1986, 
Addison-Wesley  Publishing  Company. 
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optional.  If  attempting  to  expedite  the  RFC,  it  is  permissible  to  take  the  RFC  to  the  point  of  “Rec- 
ommended for  Ballot”  before  getting  the  number  assigned  (see  Section  8.2). 

To  prepare  a new  RFC,  choose  one  of  these  methods: 

• Manual  form  production:  Photocopy  the  RFC  form  in  Appendix  B.  Type,  or  hand  print 
clearly — using  only  black  or  dark  blue  ink,  or  prepare  text  with  a word  processor — infor- 
mation defined  below  and  in  3.2.4.  Alternatively,  use  any  word  processor  or  text  editor  to 
simulate  the  appearance  of  the  RFC  form;  however,  this  will  cause  rework  later  since  both 
the  RFC  form  and  the  portion  of  the  Specification  to  be  changed  must  be  prepared  in  “inte- 
grated electronic  form”  using  the  Specification  document  processor  before  the  RFC  will  be 
included  in  any  mail  ballot. 

• Integrated  Electronic  form  production:  Refer  to  section  3.2.4  for  requirements  of  elec- 
tronic form  RFCs.  Prepare  RFC  in  conformance  with  all  requirements;  requests  for  excep- 
tions to  the  requirements  routinely  are  disallowed.  Save  to  floppy  disk,  print  a paper  copy, 
and  forward  both  to  the  IGES  Change  Control  Secretary.  CAUTION:  the  secretary  will 
assign  an  RFC  number  based  on  the  paper  copy  without  checking  the  electronic  form  for 
conformance  with  section  3.2.4  requirements.  However,  non-conforming  RFCs  will  not  be 
included  in  any  mail  ballot.  The  RFC  author  and  the  custodian  committee  jointly  are 
responsible  to  ensure  complete  conformance.  The  IGES  Editorial  Committee  may  be  con- 
sulted for  assistance,  but  is  not  responsible  for  doing  this  work. 


Minimum  information  requirements  for  a New  RFC  are: 

1.  Name,  mailing  address,  and  telephone  number  of  the  author  of  (or  contact  for)  the  new  RFC. 

2.  Optionally,  for  RFCs  extending  the  Specification,  identification  of  two  or  more  systems  hav- 
ing a similar  capability. 

Minimum  structure  requirements  for  a New  RFC  are: 

1 . RFC  Title  - Short  but  descriptive. 

2.  Problem  and  impact  statement  - A statement  expressing  the  shortcoming  or  error  in  the  current 
Specification,  along  with  an  indication  of  the  impact  of  this  problem. 

3.  Proposed  solution  - A technical  description  of  the  change  to  the  Specification  that  is  being 
proposed,  along  with  an  explanation  of  how  this  is  a solution  to  the  problem  described. 

General  Guidelines  For  Originating  RFCs  are: 

1.  Two  or  more  entities  that  are  related  to  each  other  must  be  included  in  a single  RFC.  When  a 
new  entity  must  point  to  another  new  entity  from  its  Directory  Entry,  Parameter  Data,  or 
Additional  Pointers  lists,  it  is  counterproductive  to  separate  them  because  confusion  will 
result  if  one  RFC  is  approved  and  the  other  is  not. 

2.  The  problem  statement  and  proposed  solution  should  clearly  identify  affected  passages  by  (a) 
IGES  version  number,  (b)  section  number,  and  (c)  page  number.  For  example,  use  a phrase 
such  as  “IGES  Version  5.0,  Section  4.59,  third  paragraph  on  page  226.”  All  RFCs  must  refer 
to  the  latest  available  version  of  the  Specification  when  they  are  initiated. 

3.  Entities  should  be  referenced  by  both  type  and  form  numbers.  There  must  be  a distinction 
between  the  instance  of  an  entity  and  its  name;  names  are  proper  nouns  and  are  capitalized 
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(except  for  the  word  “entity”).  For  example,  the  Witness  Line  entity  (Type  106,  Form 
40)...”  is  a reference  to  the  name,  while  the  phrase  “...the  visible  segments  of  a witness  line...” 
is  a reference  to  an  instance  of  the  entity.  When  adding  one  new  type , the  entity  type  should  be 
specified  as  the  RFC  number  (without  suffix)  assigned  by  the  Change  Control  Secretary,  and 
the  numbering  of form(s)  should  be  ascending  starting  at  1.  (The  permanent  type  number  will 
be  assigned  by  the  IGES  E 'tor  when  the  change  is  incorporated  into  the  Specification.)  The 
RFC  Form’s  proposed  solution  should  indicate  the  numeric  range  (e.g.,  RFC  999D  might 
use  “Add  the  Essential  entity  (Type  999,  Forms  1-20)  in  the  300-series  of  entities”).  If  one 
form  is  being  added  to  an  existing  entity  type,  the  entity  form  should  be  specified  as  the  RFC 
number  (without  suffix).  When  adding  multiple  new  types  or  multiple  new  forms  to  existing 
types,  use  a unique  alphabetic  prefix  to  the  RFC  number  (e.g.,  RFC  987B  might  use  “Add  the 
Magnificent  Definition  entity  (Type  A987,  Forms  1-5)  in  the  300-series  and  the  Magnificent 
Instance  Entity  (Type  B987,  Forms  1-5)  in  the  400-series,  and  add  forms  C987-E987  to  the 
Point  Entity  (Type  116)”).  If  changing  the  Global  section,  use  a phrase  such  as  “next  available 
3 parameters.”  If  the  RFC  is  so  complicated  that  the  above  guidelines  might  cause  more  con- 
fusion than  clarification,  consult  the  IGES  Editor,  Change  Control  Secretary,  or  the  IGES 
Project  Committee  for  guidance. 

RFC  Cover  Sheet  Information  Recorded  During  This  Stage: 

Date  the  new  RFC  was  received. 

RFC  Number  assigned. 

RFC  Title. 

Name,  mailing  address,  and  telephone  number  of  the  author  of  the  new  RFC. 

When  supplied,  identification  and  attachment  of  the  electronic  form  of  the  new  RFC. 

RFC  Actions  Taken  During  This  Stage: 

1 . The  Change  Control  Secretary  examines  new  RFCs  received  for  adherence  to  the  minimum 
requirements.  Return  contact  is  made  with  authors  of  new  RFCs  that  do  not  meet  the  mini- 
mum requirements  so  they  may  be  resubmitted. 

2.  The  Change  Control  Secretary  originates  an  RFC  Cover  Sheet  for  each  new  RFC  meeting  the 
minimum  requirements. 

3.  The  Change  Control  Secretary  archives  each  RFC  Cover  Sheet  and  the  associated  documenta- 
tion making  up  the  original  RFC. 


3.2.2  IGES  Project  Committee  Coordination 

The  Change  Control  Secretary  delivers  all  new  RFCs  to  the  IGES  Project  Committee  in  a timely 
manner.  This  means  all  new  RFCs  collected  since  the  previous  meeting  of  the  IPO  General 
Assembly  are  distributed  beforehand  to  this  committee  in  preparation  for  consideration  at  the  fol- 
lowing meeting. 

At  the  IPO  meeting,  the  IGES  Project  Committee  examines  each  new  RFC  and  decides  whether 

or  not  Gray  Page3  testing  is  required;  these  data  appear  on  the  integrated  RFC  form.  The  IGES 
Project  Committee  designates  a custodian  committee  to  be  responsible  for  the  RFC.  Technical 
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Committees  sharing  an  interest  in  the  RFC  are  termed  “joint-interest  committees”  and  also  are 
identified  to  the  extent  possible  at  this  time. 

These  actions  are  considered  to  be  official  business  by  the  IGES  Project  Committee. 

Typically,  an  RFC  addressing  a specific  technical  issue  is  assigned  to  an  IPO  Technical  Commit- 
tee on  the  basis  of  subject  matter,  while  an  RFC  addressing  a broad  issue  or  having  a broad  scope 
relative  to  the  Specification  will  be  assigned  to  the  Implementors'  Committee  or  to  the  IGES 
Project  Committee  itself. 

RFC  Cover  Sheet  Information  Recorded  During  This  Stage: 

tta  Date  of  the  IGES  Project  Committee  meeting  at  which  new  RFC  was  first  considered. 
tta  Indication  of  whether  or  not  Gray  Page  testing  is  required,  verify  the  same  indication  on  the 
RFC  Form. 

eta  Custodian  committee  assigned.  Joint-interest  committees  assigned  (if  any). 
eta  Optionally,  comments  or  recommendations  to  the  custodian  committee. 
eta  Optionally,  for  RFCs  extending  the  Specification,  identification  of  two  or  more  systems  hav- 
ing a similar  capability. 

RFC  Actions  Taken  During  This  Stage: 

1 . Approximately  one  month  before  an  upcoming  meeting,  the  Change  Control  Secretary  distrib- 
utes a copy  of  each  new  RFC  received  to  members  of  the  IGES  Project  Committee  for  their 
review. 

2.  For  each  new  RFC,  the  originally  archived  Cover  Sheet  is  updated  by  the  Change  Control 
Secretary  to  reflect  the  determinations  made  during  the  IGES  Project  Committee  coordination. 

3.  For  each  new  RFC,  the  Change  Control  Secretary  supplies  the  Chairperson  of  the  custodian 
committee  with  the  updated  Cover  Sheet,  the  associated  documentation,  and  the  electronic 
form  if  available. 

4.  For  each  new  RFC,  the  custodian  committee  chairperson  supplies  the  RFC  author  with  a copy 
of  the  Cover  Sheet  received  from  the  Change  Control  Secretary. 

5.  If  Gray  Page  testing  is  required  for  the  RFC,  the  Change  Control  Secretary  supplies  the  head 
of  the  Gray  Page  Committee  with  a copy  of  the  updated  Cover  Sheet  and  any  associated  doc- 
umentation. 


3.2.3  Custodian  Committee  Coordination 

The  custodian  committee  for  an  RFC  is  responsible  for  the  technical  coordination  of  that  RFC. 
The  outcome  of  the  coordination  activity,  shown  in  Figure  2,  is  reported  back  to  the  IGES  Project 
Committee  for  oversight  review  and  final  approval.  Within  custodian  committees,  technical  coor- 
dination of  new  RFCs  will  be  scheduled  in  as  timely  a manner  as  possible. 


3.  Beginning  with  IGES  version  5.3,  entries  designated  Gray  Pages  will  not  be  in  a separate  section  and  will 
be  flagged  as  untested. 
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Figure  2.  The  Custodian  Committee  Coordination  and  Project  Committee  Oversight  Review  Process 


The  technical  deliberations  of  the  custodian  committee  may  result  in  issuing  a revision  of  the 
RFC.  The  custodian  committee  chairperson  shall  coordinate  RFC  revision  process.  He  shall 
ensure  that  the  reason  for  revision  is  entered  on  the  cover  sheet  and  that  revisions  are  adequately 
distributed. 

The  custodian  committee  is  responsible  for  managing  the  participation  of  joint-interest  commit- 
tees in  the  technical  coordination  of  the  RFC. 

All  balloted  RFCs  appear  in  their  “integrated  form,”  i.e.,  they  accurately  illustrate  how  the  Speci- 
fication would  look  should  the  proposed  change  actually  be  made  (except  that  the  type  and  form 
numbers  may  be  temporary  values  based  on  the  RFC  number).  Logically  complete  porti  -s  of  the 
Specification  will  be  depicted.  In  general,  this  means  full  pages  upon  which  changes  occur.  If  the 
first  and  last  page  of  a 30-page  entity  description  change,  common  sense  suggests  only  those  two 
pages  must  be  depicted,  but  if  2 pages  in  a 4-page  description  change,  all  4 pages  should  be 
depicted.  The  IGES  Editor  and  IGES  Project  Committee  shall  jointly  determine  what  constitutes  a 
“logically  complete”  depiction.  Producing  the  integrated  form  of  an  RFC  requires  both  the  elec- 
tronic masters  and  access  to  the  document  processor  used  to  prepare  the  Specification  for  publica- 
tion. 

It  is  assumed  that  RFCs  will  exist  in  the  “integrated  electronic”  format  prior  to  the  editorial 
review  cycles  identified  below.  Although  technical  assistance  for  this  will  be  available  through  the 
IGES  Editor  and  the  Editorial  Committee,  custodian  committees  have  the  responsibility  to  see 
that  RFCs  are  generated  and  maintained  in  the  electronic  format.  With  respect  to  technical  coordi- 
nation, an  RFC  will  always  be  designated  to  belong  to  one  of  the  following  states: 
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Unassigned:  RPC  has  been  accepted  by  the  Change  Control  Secretary  but  has  not  been 
assigned  to  a custodian  committee  by  the  IGES  Project  Committee. 

Open:  RFC  has  been  assigned  to  a custodian  committee  by  the  IGES  Project  Committee 
as  an  “active”  work  item  of  the  custodian  committee.  The  custodian  committee  is  respon- 
sible for  coordinating  the  RFC’s  advancement  through  the  approval  process. 

Tabled:  RFC  is  being  held  by  the  custodian  committee  for  future  action. 

Transferred:  RFC  has  been  returned  from  the  custodian  committee  to  the  IGES  Project 
Committee  for  reassignment  with  Open  status  to  a different  custodian  committee  because 
the  current  custodian  committee  feels  the  RFC  is  not  within  its  area  of  expertise;  the  IGES 
Project  Committee  may  reassign  or  return  the  RFC. 

Recommended  for  Ballot:  RFC  has  been  reviewed  by  the  custodian  committee  both  tech- 
nically and  editorially,  and  the  committee  consensus  favors  approval. 

Approved  for  Ballot:  A “Recommended  for  Ballot”  RFC  has  been  reviewed  and 
approved  by  the  IGES  Project  Committee  and  will  be  included  in  the  next  mail  ballot  pro- 
vided the  “integrated  electronic  form”  is  complete  and  correct. 

Balloted:  RFC  mail  ballot  results  have  been  received  and  forwarded  to  the  custodian  com- 
mittee for  coordination. 

Recommended  for  Gray  Pages:  RFC  has  been  affirmed  by  the  voting  and  ballot  com- 
ment resolution  process,  and  the  custodian  committee  consensus  is  that  the  proposal 
should  be  labeled  as  UNTESTED  Appendix  of  in  the  Specification  until  testing  require- 
ments are  completed. 

Recommended  for  Update:  RFC  has  been  affirmed  by  the  voting  and  ballot  comment 
resolution  process,  and  the  custodian  committee  consensus  is  that  the  proposal  should  be 
incorporated  into  the  main  body  of  the  Specification  immediately  because  no  testing  is 
required  or  the  required  testing  has  been  completed.  This  status  may  be  assigned  immedi- 
ately after  balloting  or  following  future  successful  Gray  Page  testing. 

Edit  Change  Order  (ECO):  A “Recommended  for  Gray  Pages”  or  “Recommended  for 
Update”  RFC  has  been  approved  by  the  IGES  Project  Committee  and  will  be  incorporated 
into  the  next  version  of  the  Specification. 

Reviewed:  RFC  has  received  “oversight”  review  by  the  IGES  Project  Committee  follow- 
ing the  assignment  of  one  of  the  “recommended”  states  by  the  custodian  technical  com- 
mittee, but  the  IGES  Project  Committee  rejects  the  “recommended”  status  for  specific 
reason(s).  The  RFC  is  returned  to  the  custodian  technical  committee  to  resolve  the  prob- 
lem^). 

Cancelled:  RFC  has  been  removed  from  further  consideration  by  its  custodian  committee; 
this  may  occur  before  or  after  balloting.  This  status  may  be  appealed  to  the  IGES  Project 
Committee  if  the  author  disagrees  with  the  custodian  committee's  decision. 

Withdrawn:  RFC  has  been  removed  from  further  consideration  by  its  author;  this  may 
occur  at  any  time  subject  to  acceptance  by  the  custodian  committee  (if  withdrawal  is  to  be 
rejected  by  the  custodian  committee,  it  must  first  identify  an  alternate  author  to  assume 
responsibility  for  the  RFC). 


The  designation  of  these  states  (except  Open,  Approved  for  Ballot  and  ECO)  is  considered  official 
business  of  the  custodian  committee.  The  designation  of  Open,  Approved  for  Ballot  and  ECO 
states  is  considered  official  business  of  the  IGES  Project  Committee.  All  state  assignments  must 
be  promptly  communicated  to  the  IGES  Change  Control  Secretary  by  the  appropriate  committee 
chairman. 
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The  custodian  committee  chairperson  reports  to  the  IGES  Project  Committee  whenever  one  of  the 
states  recommended  is  reached  (any  of  the  three).  Transferred,  Withdrawn,  or  Cancelled.  The 
report  summarizes  the  history  and  present  situation  for  the  RFC.  The  IGES  Project  Committee 
exercises  oversight  review  to  ensure  policies  and  procedures  have  been  followed  properly  and  to 
determine  if  there  are  any  reasons  why  the  status  of  the  RFC  being  presented  is  inappropriate. 

For  Recommended  RFCs,  the  IGES  Project  Committee  will: 

• approve  the  proposed  status,  or 

• approve  the  proposed  status  on  the  condition  that  specified  additional  work  be  done  by  the 
custodian  committee,  or 

• refuse  approval  and  return  the  RFC  to  the  custodian  committee  with  "Reviewed"  status. 

The  IGES  Projec'  Committee  may  refuse  approval  only  on  the  basis  of  an  issue  that  is  of  a global 
nature  for  the  Spe  cation.  The  issue  cannot  be  of  a specific  technical  nature  for  which  the  custo- 
dian committee  or  a joint-interest  committee  could  claim  expertise.  Sections  3.3.1,  3.4.3,  and 
3.5.2  address  oversight  review  in  more  detail  for  each  of  the  Recommended  states. 

For  Cancelled  or  Withdrawn  RFCs,  the  IGES  Project  Committee  will  either: 

• approve  the  proposed  status,  or 

• decide  on  an  alternative  course  of  action. 

For  Transferred  RFCs,  the  IGES  Project  Committee  will  either: 

• approve  the  status  and  appoint  a new  custodian  committee  to  receive  the  RFC  with 
“Open”  status,  or 

• disapprove  the  status  and  send  the  RFC  back  to  the  same  custodian  committee  with 
“Open”  status.  It  is  assumed  that  “Transferred”  status  will  be  assigned  at  the  beginning  of 
RFC  consideration  rather  than  after  much  work  (such  as  balloting)  has  been  completed. 

The  above  actions  are  considered  official  business  on  the  part  of  the  IGES  Project  Committee. 

For  recommended  RFCs,  Figure  3 illustrates  the  relation  among  the  technical  coordination  pro- 
cess, the  editorial  review  process,  and  the  IGES  Project  Committee  oversight  review  process.  The 
“Recommended  for  Ballot”  state  for  an  RFC  implies  that  the  iterative  process  depicted  in  the  fig- 
ure between  the  custodian  committee  and  the  IGES  Editor  has  been  satisfactorily  completed.  It  is 
possible  that  the  editorial  review  cycle  will  result  in  editorial  changes  to  the  RFC  and  a new  ver- 
sion will  need  to  be  produced  and  recommended.  Editorial  corrections  after  balloting  are  not 
intended  to  result  in  repeat  balloting.  (This  is  consistent  with  the  fact  that  any  editorial  corrections 
may  be  made  at  any  time  without  balloting  with  approval  of  the  IGES  Editor  and  the  IGES  Project 
Committee.) 


13 


Operating  Procedures  and  Life  Cycle  for  IGES 


* Recommendation  is  for  RFC  Ballot,  Gray  Page  Testing,  or  Update 


Figure  3.  Custodian  Committee  Technical  Coordination  and  Editorial  Review  of  RFCs 


The  objective  of  the  editorial  review  cycle  between  the  IGES  Editor  and  the  custodian  committee 
is  to  come  to  a mutual  agreement  that  the  RFC  is  in  the  proper  form,  and  that  its  statement  is  clear, 
succinct,  and  complete.  This  objective  reflects  the  requirement  that  the  proposed  change  to  the 
Specification  must  not  only  improve  the  Specification,  but  must  also  be  able  to  be  easily  and 
unambiguously  evaluated  at  ballot  time  by  the  voting  members  of  the  IPO  General  Assembly. 

It  is  the  responsibility  of  the  custodian  committee  to  initiate  and  maintain  momentum  in  the  edito- 
rial review  process. 

Editorial  Review  Operating  Principles: 

1.  Ensure  that  the  General  Guidelines  For  Originating  RFCs,  Section  3.2.1,  have  been  followed. 

2.  Maintain  consistency  of  style  across  RFCs. 

RFC  Cover  Sheet  Information  Recorded  During  This  Stage: 

Identification  (with  associated  dates)  and  brief  description  of  the  issue  revisions  of  the  RFC 
originating  during  the  technical  coordination  process. 

For  RFCs  Withdrawn,  Transferred,  Canceled,  or  Recommended: 

Date  action  was  taken 

Issue  revision  for  which  action  taken 

Reason(s)  for  action  (all  except  Approved) 

Identification  of  accompanying  electronic  form  (if  Recommended  for  Ballot) 
Identification  (with  associated  dates)  of  joint-interest  committee  participation  in  the  techni- 
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cal  coordination  proce* r 

Date  the  summary  rep*,  was  made  to  the  IGES  Project  Committee. 

£d  IGES  Project  Committee  decision,  along  with  reasons. 

RFC  Actions  Taken  During  This  Stage: 

1 . For  each  joint-interest  committee  named  for  an  RFC,  the  custodian  committee  chairperson  has 
the  responsibility  to  supply  a copy  of  the  RFC  to  the  chairperson  of  that  committee  and  to 
manage  the  technical  coordination  of  the  RFC  with  that  committee. 

2.  The  custodian  committee  keeps  the  Cover  Sheet  up-to-date  for  each  RFC  for  which  it  has  cus- 
todianship. 

3.  The  custodian  committee  chairperson  supplies  the  Change  Control  Secretary  with  a copy  of 
each  issue  revision  of  the  RFC. 

4.  The  custodian  committee  strives  to  write  the  RFC  in  accordance  with  the  editorial  review 
principles  given  above. 

5.  For  Recommended  RFCs,  the  custodian  committee  chairperson  signs  and  dates  the  correct 
issue  revision  of  the  RFC  Form. 

6.  The  custodian  committee  chairperson  reports  to  the  IGES  Project  Committee  whenever  any 
one  of  the  states  Withdrawn,  Transferred,  Cancelled,  or  Recommended  is  reached  and  sup- 
plies the  Change  Control  Secretary  with  an  updated  Cover  Sheet  and  the  latest  issue  revision 
of  the  RFC  Form. 

7.  For  each  RFC  reported,  the  Change  Control  Secretary  accepts  the  latest  issue  revision  of  the 
RFC  Form  and  the  updated  Cover  Sheet  from  the  custodian  committee.  The  Secretary  updates 
the  Cover  Sheet  to  reflect  the  IGES  Project  Committee  decision  and  subsequently  updates  the 
archives. 


3.2.4  The  RFC  Form  - Guidelines  and  Electronic  Aspects 

This  section  examines  the  RFC  Form,  both  as  a paper  document  and  as  an  electronic  document. 
Guidelines  for  Completing  the  RFC  Form: 

See  Appendix  B for  a copy  of  a blank  RFC  Form.  The  contents  of  the  RFC  Form  and  their  defini- 
tions are  as  follows. 

Contents  of  the  Cover  Sheet  are: 

1.  Date  - Date  the  RFC  was  received  by  the  Change  Control  Secretary 

2.  RFC  Number  - Sequential  number  assigned  by  the  Change  Control  Secretary  in  the  order 
RFCs  are  received 

3.  Title  - Short,  descriptive  title  for  the  RFC 

4.  Author  - Name,  mailing  address,  telephone  number,  and  optionally  FAX  number  and  e-mail 
address  of  the  person  to  be  contacted  about  this  RFC.  If  this  person  is  not  the  author,  also  list 
the  actual  author’s  name. 

5.  Custodian  TC  - The  IGES  committee  responsible  for  the  RFC. 

6.  Gray  Page  Testing  - Yes  or  No  depending  on  whether  or  not  this  testing  is  required. 

7.  Issue  Revision  - A,  B,  C,  etc.  denoting  the  revision  of  this  RFC. 

8.  Revision  Date  - The  date  work  on  this  issue  revision  began. 
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9.  ECO  Number  - Signifies  that  “Recommended  for  Gray  Pages”  or  “Update”  status  was 
upheld  in  oversight  review  by  the  IGES  Project  Committee. 

10.  Contents  of  succeeding  pages  (numbered  2-n,  and  with  the  assigned  RFC  number  in  the 
header): 

1 1 . Problem  Description  - A statement  expressing  the  shortcoming  or  error  of  the  current  Speci- 
fication, along  with  an  indication  of  the  impact  of  this. 

12.  Proposed  Solution  - A technical  description  of  the  change  to  the  Specification  being  pro- 
posed, along  with  an  explanation  of  how  this  solves  the  problem  described. 

Guidelines  For  The  Electronic  Form  Of  RFCs: 

Section  3.2.1  offers  the  option  of  submitting  an  RFC  in  electronic  form4  (in  addition  to  the 
required  paper  form)  to  obtain  a number  from  the  IGES  Change  Control  Secretary.  Although  hav- 
ing the  RFC  in  electronic  form  is  optional  for  getting  a new  number,  it  is  mandatory  for  getting 
the  RFC  to  “Approved  for  Ballot”  status;  this  policy  has  been  adopted  to  reduce  the  problems 
caused  in  the  past  when  the  RFC  wording  was  inconsistent  with  the  Specification  and  the  IGES 
Editor  had  to  resolve  the  discrepancy. 

The  most  important  concept  of  the  electronic  form  RFC  is  called  “integration”;  this  means  that  the 
actual  RFC  text  is  inserted  into  a temporary  copy  of  the  Specification  to  which  it  applies.  This 
portion  can  then  be  processed  and  printed  to  depict  the  actual  appearance  of  the  Specification  as  if 
the  proposal  were  approved. 

Integration  offers  significant  advantages: 

• consistency  is  assured  because  the  actual  text  is  changed; 

• rework  is  avoided  by  making  the  change  once; 

• accuracy  is  improved  by  eliminating  data  reentry; 

• comprehension  is  enhanced  because  voters  see  the  proposal  “in  context”  rather  than  as  iso- 
lated editing  instructions. 

The  disadvantages  are: 

• Work  is  shifted  from  the  end  of  the  RFC  process  to  its  beginning;  therefore,  this  work  is 
wasted  if  the  RFC  is  not  approved.  (This  may  be  an  advantage  since  it  encourages  authors 
to  research  their  change  and  identify  support  before  going  to  the  trouble.) 

• Extra  work  may  discourage  authors  from  submitting  useful  RFCs 

• Integration  deemphasises  deletions,  so  proposals  that  require  only  deletion  may  be  less 
understandable  than  an  editing  directive  such  as  “delete  paragraph  1 on  page  10.” 

• Preparing  the  “integrated”  form  requires  access  to  the  electronic  master  of  the  Specifica- 
tion as  well  as  the  document  processing  software 

Version  5.1  of  the  Specification  was  prepared  using  IATEX  (a  public  domain  application)  for  the 
body  text  and  IGESDRAW™  for  IGES  illustrations. 

IATeX  is  called  a text  formatter  because  it  uses  markup  symbols  to  specify  what  the  document 


4.  The  software  products  cited  in  this  section  are  intended  to  indicate  possible  applications  for  use  and  are 
not  necessarily  endorsed  by  the  authors  or  their  employers. 


16 


Operating  Procedures  and  Life  Cycle  for  IGES 


will  look  like  when  printed  (e.g.,  \PAR  marks  the  beginning  of  a paragraph  and  \SECTION  indi- 
cates section  title);  this  differs  from  word  processors  that  typically  display  the  page  work  area  to 
look  like  its  printed  appearance. 

IATEX  input  is  relatively  easy  to  prepare,  especially  when  limited  changes  are  involved;  even 
extensive  new  sections  are  manageable  by  starting  with  an  existing  section  that  is  similar  to  the 
new  information  to  be  added.  The  IGES  Editorial  Committee  will  make  portions  of  the  Specifica- 
tion available  upon  request  between  meetings;  electronic  copies  of  the  Specification  also  will  be 
available  on  a personal  computer  at  the  IPO  meetings.  RFC  authors  without  access  to  an  appropri- 
ate computer  between  meetings  should  obtain  assistance  from  the  custodian  committee’s  chair- 
person. 

New  RFC  authors  planning  to  prepare  the  electronic  form  should  refer  to  existing  RFCs.  Exam- 
ples may  be  obtained  from  the  IGES  Project  to  enable  comparison  of  the  visual  appearance  of  an 
RFC  Form  to  the  IATEX  input  that  generated  it.  This  will  aid  in  understanding  how  to  modify  the 
IATEX  input  to  obtain  desired  results. 

When  prior  arrangements  have  been  made  with  the  IGES  Editor,  the  IATEX  input  text  may  be  pre- 
pared in  the  native  format  of  the  originating  word  processor  for  the  RFC  (WordPerfect™ , 
Microsoft  Word™ , etc.).  In  the  absence  of  such  an  arrangement,  the  IATEX  input  should  be  ASCII 
text.  When  ASCII  text  is  submitted,  each  line  should  be  terminated  by  a “line  feed”  sequence 
(<CRxLF>  or  <NL>).  Lines  should  not  exceed  80  characters.  Paragraphs  should  be  separated  by 
a single  blank  line.  In  general,  printing  the  text  file  on  a monitor  screen  or  a printer  should  yield 
results  resembling  how  the  final  version  should  appear  (with  allowances  for  the  text  formatting 
markup  symbols  that  are  present). 

Submission  of  new  RFC  material  in  electronic  form  to  the  Change  Control  secretary  must  use 
either  e-mail  or  floppy  disks.  Internet  submissions  use  an  exploder  (iges@eeel.nist.gov)  to  dis- 
tribute and  archive  the  submitted  RFC.  A floppy  disk  (any  format  or  density)  also  is  acceptable. 
Disks  should  be  clearly  labeled  on  their  paper  label  with  the  author's  name,  the  RFC  number  (if 
assigned),  the  operating  system,  and  the  density;  otherwise,  time  will  be  wasted  experimentally 
reading  the  disk  to  identify  its  format. 

Material  submitted  in  electronic  form  for  an  illustration  within  an  RFC  must  be  submitted  as  an 
IGES  file  unless  the  illustration  cannot  be  depicted  in  IGES  (e.g.,  a photograph);  discuss  use  of 
any  non-IGES  artwork  with  the  IGES  Editor  in  advance  of  RFC  preparation.  Use  one  IGES  file  in 
ASCII  (non-compressed)  form  for  each  illustration.  Include  only  the  illustration  itself,  without 
borders  or  captions.  An  illustration  may  be  either  full  page  [15x20  cm  (6x8  inches)  portrait]  or 
half  page  [15x10  cm  (6x4  inches)  landscape].  The  file  must  be  one-to-one  scale.  Text  must  be 
font  0 (standard  block)  and  a minimum  of  5 mm  (0.2  inch)  in  height  (smaller  text  may  not  repro- 
duce clearly).  Text  used  for  explanatory  annotation  should  be  6 mm  (0.25  inch).  It  is  preferred,  but 
not  required,  that  all  data  be  two-dimensional  and  defined  in  the  XY  plane,  i.e.,  surface  and  solid 
entities  should  not  be  used.  Dimension  entities  are  acceptable.  Any  RFC  author  lacking  access  to 
a CAD  system  that  can  generate  an  acceptable  IGES  file  should  seek  help  from  the  custodian 
committee’s  chairperson  or  from  the  IGES  Editorial  Committee. 
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Ballot-Ready  form: 

An  RFC  is  in  “integrated  electronic  form”  (i.e.,  “ballot-ready”)  when: 

• editorial  review  of  RFC  content  by  the  IGES  Editorial  Committee  has  been  completed, 

• both  the  RFC  Form  and  proposed  changes  to  the  Specifications  have  been  prepared  for  and 
processed  correctly  by  the  designated  document  processor  for  the  Specification  (currently 
IATeX), 

• any  illustrations  exist  as  IGES  files  that  have  been  prepared  for  and  processed  correctly  by 
the  designated  IGES  post-processor  for  the  Specification  (currently  IGESDraw™), 

• printed  output  has  been  produced  from  the  electronic  input  for  delivery  to  the  Change 
Control  Secretary  along  with  the  e-mail  or  floppy  disk(s)  containing  the  electronic  input. 

3.3  The  RFC  Ballot  Process 

This  section  specifies  the  process  by  which  RFCs  are  given  final  approval  for  ballot  and  balloted 
within  the  IPO  General  Assembly.  This  section  also  specifies  how  ballots  are  summarized  and 
evaluated,  and  how  individual  ballot  comments  are  handled. 

3.3.1  Oversight  Review  for  Ballot  Approval 

The  IGES  Project  Committee  performs  oversight  review  for  ballot  approval  on  each  RFC  reach- 
ing “Recommended  For  Ballot”  status  upon  request  of  the  custodian  committee's  chairperson, 
who  has  verified  the  completion  of  these  actions: 

• RFC  content  has  been  approved  by  the  IGES  Editorial  committee. 

• Custodian  committee  has  reached  consensus  on  approval  of  the  RFC  for  ballot. 

The  request  for  oversight  review  is  a report  containing  at  least  the  following: 

1.  A high-level  (i.e.,  the  “gross  differences”)  comparison  between  the  RFC  originally  submitted 
by  the  author  and  the  RFC  that  has  reached  “Recommended  For  Ballot”  status  if  significantly 
changed. 

2.  The  role  of  joint-interest  committees  and  the  results  of  their  participation. 

3.  A summary  of  how  consensus  was  obtained. 

4.  The  Gray  Page  Test  Plan,  when  this  testing  is  required.  See  Section  3.4.1. 

Ballot  Oversight  Review  Operating  Principles: 

1 . An  RFC  shall  be  capable  of  being  considered  and  balloted  as  an  independent,  self-contained 
item.  It  shall  not  depend  upon  other  RFCs  not  yet  in  final  ECO  form  for  its  validity,  its  correct- 
ness, or  its  completeness. 

2.  An  RFC  should  not  conflict  with  or  duplicate  another  RFC  in  any  stage  of  processing.  (A  con- 
text-searchable index  of  all  RFCs  is  available  at  IPO  meetings  or  by  request  to  the  Change 
Control  Secretary.) 

3.  There  should  be  technical  consistency  across  RFCs. 

Options  for  the  IGES  Project  Committee  following  oversight  review  were  given  in  Section  3.2.3. 
If  all  criteria  are  met,  the  RFC  is  assigned  “Approved  for  Ballot”  status  by  the  IGES  Project  Com- 
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mittee;  this  status  may  be  made  conditional  on  completion  of  procedural  requirements  such  as 
minor  editorial  corrections. 

If  the  oversight  review  results  in  an  RFC  approved  or  conditionally  approved  for  ballot,  a ballot- 
ready  form  of  the  RFC  must  be  supplied  to  the  Change  Control  Secretary.  In  many  cases,  because 
of  the  editorial  review  that  has  occurred,  the  RFC  as  presented  for  oversight  review  already  will 
be  ballot-ready.  However,  if  this  is  not  possible  at  the  time  of  oversight  review,  or  if  the  oversight 
review  itself  results  in  editorial  changes,  the  custodian  committee  chairperson  can  make  arrange- 
ments with  the  Change  Control  Secretary  for  supplying  a ballot-ready  form  of  the  RFC  at  a later 
date.  (The  custodian  committee  chairperson  decides  whether  to  return  the  ballot-ready  form  to  the 
committee  for  final  review;  the  RFC  need  not  return  to  the  IGES  Project  Committee  unless  the 
custodian  committee  decides  to  change  it  again.)  Arrangements  made  with  the  Change  Control 
Secretary  must  take  into  account  the  Secretary's  responsibility  to  supply  the  Ballot  Coordinator 
with  all  ballot-ready  RFCs  in  time  for  the  next  RFC  ballot. 

RFC  Cover  Sheet  Information  Recorded  At  This  Stage: 

Identification  (with  associated  dates)  of  joint-interest  committee  participation  in  the  techni- 
cal coordination  process. 

Date  the  summary  report  was  made  to  the  IGES  Project  Committee. 

RFC  Actions  Taken  at  This  Stage: 

1.  See  items  5,  6,  and  7,  Section  3.2.3. 

2.  The  Change  Control  Secretary  supplies  the  IGES  Ballot  Coordinator  with  the  ballot-ready 
copy  of  all  RFC  Forms  that  have  been  given  final  approval  for  ballot.  As  a means  of  double- 
checking the  contents  of  the  upcoming  ballot,  the  Secretary  also  mails  a copy  of  the  RFC 
Forms  to  the  IGES  Editor  and  the  IGES  Project  Manager. 


3.3.2  The  RFC  Ballot 

The  RFC  (mail)  ballot  is  the  process  by  which  voting  members  of  the  IPO  General  Assembly  can 
comment  on  and  vote  approval  or  disapproval  of  one  or  more  RFCs.  Normally,  RFC  ballot  peri- 
ods span  successive  IPO  meetings,  so  there  is  an  alternating  cycle  of  mail  ballots  and  IPO  meet- 
ings. 

RFCs  that  have  been  given  approval  for  ballot  through  oversight  review  by  the  IGES  Project 
Committee  are  eligible  for  RFC  ballot.  Eligible  RFCs  are  automatically  included  in  the  next  RFC 
ballot. 

The  RFC  Form  portion  of  each  RFC  is  what  is  actually  included  in  the  RFC  ballot. 

For  each  RFC  ballot  conducted,  the  IGES  Ballot  Coordinator  assembles  and  mails  a ballot  pack- 
age to  each  member  of  the  Ballot  Group.  Each  ballot  recipient  should  return  the  ballot  by  the 
stated  deadline. 

The  IGES  Ballot  Group  concept  is  intended  to  avoid  the  cost  of  wasted  mailings  to  the  90  percent 
of  IPO  members  who  do  not  vote.  Any  voting  member  of  the  IPO  may  become  a member  of  the 
Ballot  Group  by  request,  and  will  remain  in  the  group  until  the  member  requests  removal.  All  IPO 
members  who  become  qualified  to  vote  will  be  mailed  one  ballot  that  includes  a “request  form”  to 
become  a member  of  the  Ballot  Group.  Members  who  do  not  vote  or  return  the  request  form  will 
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not  receive  future  ballots.  However,  if  they  want  to  resume  voting  in  the  future,  they  may  do  so  by 
sending  a written  request  to  the  IGES  Ballot  Coordinator,  who  will  add  them  to  the  Ballot  Group. 

An  RFC  ballot  form  shall  be  provided  by  the  IGES  Ballot  Coordinator.  This  form  identifies  the 
RFCs  being  balloted  and  records  the  vote  registered.  Voting  choices  are:  Approve,  Approve  With 
Comment,  Disapprove  (comment  giving  reasons  is  required),  and  Abstain. 

Ballot  recipients  returning  a ballot  cast  their  vote5  on  each  RFC.  If  a returned  ballot  does  not  indi- 
cate a choice  of  Approve,  Approve  With  Comment,  or  Disapprove  for  a particular  RFC,  the  vote 
for  that  RFC  is  interpreted  as  “Abstain.” 

As  described  in  Section  3.3.4,  an  RFC  may  possibly  be  balloted  more  than  once  as  a result  of 
technical  modifications  arising  from  comments;  in  such  cases,  the  RFC  version  is  incremented. 

3.3.3  Ballot  Summary  and  Ballot  Evaluation 

After  an  RFC  has  been  included  in  the  mail  ballot,  it  is  assigned  “Balloted”  status.  RFC  ballot 
results  are  summarized  and  evaluated  for  each  RFC. 

A Ballot  Summary  Report  is  prepared  by  the  IGES  Ballot  Coordinator  following  each  RFC  ballot. 
The  Ballot  Summary  Report  contains: 

identification  of  the  RFC  ballot  being  summarized,  including  the  beginning  and  end  dates  of 
the  ballot  period, 

the  number  of  ballot  packages  sent  out  in  each  membership  category  (Vendor,  User,  General 
Interest),  and  the  total  number  sent  out, 
the  list  of  ballot  recipients, 

the  number  of  ballot  packages  unretumed  in  each  membership  category,  and  the  total  num- 
ber unretumed, 

£2  the  list  of  ballot  recipients  returning  a ballot, 

the  RFC  number,  issue  revision,  and  Title  of  each  RFC  balloted,  along  with  the  vote  tally  for 
each  RFC, 

£3  a report  of  all  comments  received,  indicating  for  each  comment  the  name,  address  and  tele- 
phone number  of  the  commentor,  and  the  voting  preference  cast  by  the  commentor.  Com- 
ments will  be  transcribed  to  the  Comment  Disposition  Form  that  will  be  delivered  to  the 
custodian  technical  committee’s  chairperson  for  use  in  processing  the  comment. 

The  Ballot  Summary  Report  is  the  basis  for  evaluation  of  the  ballot  by  the  IGES  Project  Commit- 
tee. The  purpose  of  the  ballot  evaluation  is  to  officially  review,  accept  and  report  the  results  of  the 
RFC  ballot  and  to  possibly  issue  statements  (comments  and/or  recommendations)  concerning  the 
RFCs  to  the  appropriate  custodian  committees.  The  report  of  the  review  and  acceptance,  along 
with  any  statements,  form  the  primary  contents  of  the  Ballot  Evaluation  Report. 

An  RFC  receiving  only  “Approve”  or  “Abstain”  votes  is  automatically  assigned  “ECO”  status  by 
the  IGES  Project  Committee;  otherwise,  it  is  returned  with  “Balloted”  status  to  the  custodian 
committee  for  resolution  of  disapprovals  and  comments. 


5.  If  the  voter  has  several  approval  comments  concerning  editorial  issues  such  as  misspellings,  one  option  is 
to  mark  up  a copy  of  the  RFC  using  a contrasting  color  and  mail  it  with  your  ballot.  NOTE:  Do  not  use 
this  method  for  technical  disapproval  comments.  Do  not  fax  this  reply  since  the  color  is  lost,  making 
reading  difficult. 
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The  Ballot  Evaluation  Report  will  take  the  form  of  a cover  letter  to  the  Ballot  Summary  Report.  It 
will  also  report  on  the  manner  in  which  consensus  of  the  IGES  Project  Committee  was  achieved, 
e.g.,  at  a meeting  of  the  Committee,  by  a conference  call,  by  e-mail,  etc. 

RFC  Actions  Taken  At  This  Stage: 

1 . The  Project  Manager  performs  the  necessary  coordination  for  preparation  of  the  Ballot  Evalu- 
ation Report. 

2.  The  Ballot  Evaluation  Report  is  distributed  to  IGES  Project  Committee  members,  authors  of 
RFCs  on  the  ballot,  and  ballot  respondents.  Comment  Disposition  Forms  containing  the 
transcribed  comments  are  distributed  to  custodian  committee  chairpersons  in  time  to  allow 
scheduling  them  as  agenda  items  at  the  next  IPO  meeting. 

3.  If  an  RFC  receives  either  approval  or  disapproval  comments,  the  RFC  author  should  attempt 
to  contact  each  commentor  personally  before  the  meeting  in  an  attempt  to  resolve  each  com- 
ment; this  avoids  problems  if  the  commentor  does  not  attend  the  next  IPO  meeting.  Any  com- 
ments resolutions  handled  by  the  RFC  author  shall  be  communicated  to  the  custodian 
committee  chairperson  for  entry  on  the  Comment  Disposition  Forms. 


3.3.4  Ballot  Follow-On  Work  in  Custodian  Committees 

RFCs  that  receive  only  “Approve”  and  “Abstain”  votes  in  the  ballot  process  are  approved  and 
move  directly  to  “ECO”  status  without  return  to  the  custodian  committee. 

RFCs  receiving  approval  or  disapproval  comments  in  the  ballot  process  are  returned  to  the  custo- 
dian committee  in  the  “Balloted”  state,  and  additional  work  will  be  required  to  resolve  all  com- 
ments. 

Ordinarily,  “Approval”  comments  identify  typographical  errors  or  lack  of  clarity,  and  “Disap- 
proval” comments  identify  technical  problems.  Some  commentors  do  not  always  make  this  dis- 
tinction; therefore,  all  comments  are  classified  as  “technical”  or  “editorial.”  Both  technical  and 
editorial  comments  are  further  classified  as  “persuasive”  or  “non-persuasive.” 

All  persuasive  comments  must  be  resolved  by  amending  the  RFC;  the  custodian  committee  is 
encouraged  to  consider  any  suggestions  from  the  IGES  Project  Committee  in  the  Ballot  Evalua- 
tion Report.  If  resolving  the  comments  results  in  any  technical  changes,  the  custodian  committee 
will  vote  to  determine  if  they  change  the  intent  or  functionality  of  the  RFC.  If  intent  or  functional- 
ity changes,  the  custodian  committee  shall  return  the  amended  RFC  to  the  IGES  Project  Commit- 
tee with  “Recommended  for  Ballot”  status.  Otherwise,  the  custodian  committee  will  return  the 
amended  RFC  to  the  IGES  Project  Committee  with  “Recommended  for  Gray  Pages”  or  “Recom- 
mended for  Update”  status  depending  on  whether  Gray  Page  testing  is  required,  has  been  com- 
pleted, or  is  not  required. 

In  the  event  persuasive  technical  comments  indicate  the  RFC  cannot  be  salvaged,  the  custodian 
committee  will  encourage  the  author  to  withdraw  it,  or  as  a last  resort,  vote  to  cancel  it.  Any  RFC 
author  not  accepting  the  “Cancelled”  status  may  appeal  it  to  the  IGES  Project  Committee.  The 
RFC  is  returned  to  the  IGES  Project  Committee  with  either  “Withdrawn”  or  “Cancelled”  status. 
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Figure  4 illustrates  the  ballot  outcomes  for  an  RFC. 


RFC  Ballot  Results 


‘Project  Committee  will  make  a statement  (comment  and/or  recommendation) 
in  the  Ballot  Evaluation  Report. 


Figure  4.  RFC  Ballot  Results 


Announcement  Of  Ballot  Outcomes 

Individual  comments  on  an  RFC  ballot  are  separated  into  distinct  issues  on  the  Comment  Disposi- 
tion Form. 

The  ballot  outcome  for  each  RFC  is  summarized  in  the  minutes  of  the  custodian  committee. 

Resolution  Of  Individual  Comments 

The  requirements  concerning  resolution  of  individual  comments  are: 

1 . All  comments  received  must  be  addressed. 

2.  A concerted  effort  must  be  made  to  resolve  each  comment. 

3.  All  commentors  shall  be  advised  in  writing  of  comment  disposition  unless  they  attend  the 
technical  meeting  when  the  comment  is  addressed.  The  simplest  method  of  providing  this 
written  disposition  is  to  photocopy  the  completed  Comment  Disposition  Form  and  deliver  it  to 
the  commentor. 

Adequate  records  must  be  maintained  to  provide  evidence  of  compliance  with  these  requirements. 

Resolution  of  individual  ballot  comments  follows  the  process  outlined  in  Figure  5. 


22 


Operating  Procedures  and  Life  Cycle  for  IGES 


RFC  Ballot 

Non-Technical 


Custodian  Technical 
Committee  Review 


Technical/Persuasive 


RFC 

Amended 

Editorially 


Technical/Non-Persuasive 


Commentor 

Advised 

0 CL 

1 o c" 

<3 

oy 

1 

Yes 

Commentor 

Advised 

Comment 

Resolved 


Comment 

Resolved 

RFC 

Cancelled 

Possible 

Appeal 


Comment 

Resolved 

RFC 

Withdrawn 


RFC 

Amended 

echnically 


Comment 
Resolved 
Re-Ballot 
RFC  if 
intent 
changed 


Comment 

Unresolved 

RFC 
Unchanged 

Possible 

Appeal 


Comment 

Resolved 


Figure  5.  RFC  Comment  Resolution  in  Custodian  Committee 


Comments  will  be  organized  by  type  and  classification:  the  types  are  editorial  and  technical ; the 
classes  are  persuasive  and  non-persuasive. 

The  operating  procedures  used  by  custodian  committees  to  ensure  that  the  above  requirements  are 
met  when  this  process  is  used  are: 

Custodian  committee  responsibilities  for  each  comment  are  traceable  to  a specific  individual  who 
is  identified  in  the  minutes  of  the  custodian  committee.  In  most  cases,  this  will  be  the  author  of  the 
RFC.  In  any  case,  it  is  the  responsibility  of  the  chairperson  of  the  custodian  committee  to  see  that 
such  an  individual  is  identified.  Responsibilities  for  each  comment  include: 

• Communicating  as  necessary  with  the  commentor  concerning  the  comment  and  passing 
along  the  substance  of  this  communication  to  the  custodian  committee.  In  many  cases, 
personal  communication  with  the  commentor  prior  to  the  IPO  or  Project  meeting  can  iden- 
tify an  acceptable  resolution  of  the  comment  (i.e.,  the  commentor  compromises  by  agree- 
ing to  withdraw  the  comment  if  a specified  change  is  made). 

• Ensuring  that  the  commentor  is  informed  in  writing  of  the  categorization  of  the  comment 
by  the  custodian  committee  and  the  action  taken  upon  it.  (This  notification  is  not  required 
if  commentor  attends  the  technical  committee  meeting  because  the  commentor  will 
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receive  the  committee’s  minutes.) 

The  actions  taken  can  include  amending  the  RFC  and  recommending  it  for  “Ballot,”  “Gray  Page 
Testing,”  or  “Update”  (depending  on  the  nature  of  amendment);  requesting  the  author  withdraw  a 
non-amendable  RFC;  or  voting  to  “Cancel”  a non-amendable  RFC. 

If  RFC  authors  or  commentors  disagree  with  custodian  committee  actions,  and  reasonable 
attempts  to  resolve  the  disagreement  at  the  custodian  committee  level  fail,  the  author  or  commen- 
tor  may  appeal  to  the  IGES  Project  Committee.  The  IGES  Project  Committee's  decision  regarding 
appeals  shall  appear  in  the  minutes.  See  Section  5.0  for  more  information  on  appeals. 

The  Comment  Disposition  Form(s)  documenting  the  comment  resolution  process  are  returned  to 
the  Change  Control  Secretary  by  the  custodian  committee  chairperson. 


RFC  Actions  Taken  At  This  Stage: 

1 . For  each  RFC  balloted,  the  custodian  committee  chairperson  ensures  that  the  committee  min- 
utes contain  the  ballot  outcome  for  the  RFC. 

2.  For  each  RFC  balloted,  the  custodian  committee  chairperson  ensures  that  the  operating  proce- 
dures for  resolution  of  individual  ballot  comments  (procedures  #1  and  #2  above)  are  followed. 

3.  The  custodian  committee  chairperson  notifies  the  IGES  Project  Manager  of  any  impending 
appeal  situation. 


3.4  The  Gray  Page  Testing  Process 

Version  4.0  and  later  versions  of  The  Initial  Graphics  Exchange  Specification,  as  well  as  ANSI 
ASME  Y14.26M-1989  (Digital  Representation  For  The  Communication  of  Product  Data,  which  is 

based  on  IGES  4.0),  contain  an  Untested  Entities  Appendix,  also  referred  to  as  the  “Gray  Pages.” 
This  “Gray  Page”  technique  has  been  identified  as  causing  extra  editorial  work  and  increased 
potential  for  errors  when  entities  are  moved  into  the  main  body  of  the  Specification;  for  this  rea- 
son, after  Version  5.2,  untested  entities  will  appear  in  their  “final”  place  in  the  main  body  of  the 
Specification,  but  will  be  prefixed  by  an  UNTESTED  designation.  In  these  procedures,  the  term 
“untested  entity”  designates  an  entity  that  has  not  completed  Gray  Page  testing,  regardless  of 
whether  it  appears  in  the  Untested  Entities  Appendix  or  in  the  main  body  with  an  UNTESTED 
designation.  Implementors  are  encouraged  to  attempt  implementation  of  untested  entities,  and  are 
requested  to  inform  the  IGES  Project  Committee  if  it  becomes  apparent  that  changes  to  them  are 
required. 

Untested  entities  generally  extend  the  capability  of  the  Specification.  These  entities  have  been 
approved  in  RFC  ballot  and  have  been  tentatively  approved  within  their  custodian  committee,  but 
are  required  to  successfully  undergo  certain  testing  before  they  can  be  fully  approved  and  be 
assigned  “Recommended  for  Update”  status  by  the  custodian  committee,  and  eventually  become 
part  of  the  main  body  of  the  Specification.  This  testing  is  the  “Gray  Page”  testing  referred  to  in 
Section  2.2. 

The  procedures  in  this  section  are  intended  to  assure  that  untested  entities  are  adequately  tested 
and  results  reviewed  before  being  assigned  “Recommended  for  Update”  status.  Also,  procedures 
are  given  for  reviewing  the  results  of  Gray  Page  testing  by  the  Gray  Page  Committee. 
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3.4.1  The  Gray  Pages 

All  proposed  changes  to  the  Specification  (i.e.,  all  RFCs)  are  divided  into  two  groups,  those  that 
require  Gray  Page  testing  and  those  that  do  not.  Generally  speaking,  RFCs  requiring  this  testing 
are  extensions,  while  those  not  requiring  the  testing  are  clarifications  or  fixes.  See  Section  2.2. 
The  IGES  Project  Committee  makes  the  decision  concerning  the  group  to  which  a new  RFC  is  to 
belong.  See  Sections  3.2.2  and  3.2.3. 

After  an  RFC  that  requires  Gray  Page  testing  has  been  assigned  “Recommended  for  Gray  Pages” 
status  within  the  custodian  committee,  it  is  presented  to  the  IGES  Project  Committee  for  oversight 
review.  See  Sections  3.2.3  and  3.4.3.  If  oversight  review  results  in  approval,  the  IGES  Project 
Committee  will  assign  “ECO”  status  to  the  RFC  with  a direction  to  the  IGES  Editor  to  designate 
the  entity  as  UNTESTED.  If  Gray  Page  Testing  is  completed  prior  to  publication  of  the  next  ver- 
sion of  the  Specification,  the  IGES  Project  Committee  may  assign  “ECO”  status  again  with  a 
direction  to  the  IGES  Editor  to  remove  the  entity's  UNTESTED  designation;  otherwise,  it  will 
remain  an  UNTESTED  entity  until  testing  is  complete  and  the  custodian  committee  assigns  “Rec- 
ommended for  Update”  status. 

Successful  early  completion  of  Gray  Page  testing  will  allow  the  custodian  committee  to  assign 
“Recommended  for  Update”  status  before  oversight  review  by  the  IGES  Project  Committee, 
thereby  avoiding  the  entity’s  UNTESTED  designation. 

Gray  Page  testing  for  an  RFC  consists  of  demonstrating  the  use  of  three  processor  implementa- 
tions to  successfully  pass  information  between  three  systems.  The  information  passed  shall  be  the 
same  information  as  that  included  in  the  RFC.  It  is  understood  that  the  testing  requirements  will 
depend  greatly  on  the  nature  of  the  RFC.  For  example,  the  involvement  of  a system  capable  only 
of  visual  display  might  be  appropriate  in  some  cases,  while  a system  capable  of  making  internal 
modifications  of  the  information  being  transferred  would  be  required  in  other  cases.  The  primary 
purpose  of  Gray  Page  testing  is  to  prove  that  new  entities  are  technically  correct  and  can  be  imple- 
mented to  exchange  the  intended  information,  not  to  demonstrate  marketplace  demand.  Remov- 
ing an  entity’s  UNTESTED  designation  finalizes  it,  thereby  encouraging  more  implementations. 

For  each  new  RFC  requiring  Gray  Page  testing,  a Gray  Page  Test  Plan  for  demonstrating  the  suc- 
cessful passing  of  information  is  to  be  part  of  the  RFC  before  it  is  assigned  “Approved  for  Ballot” 
status  by  the  IGES  Project  Committee.  Origination  of  the  Test  Plan,  coordination  of  it  with  the 
Gray  Page  Committee,  and  finalization  of  it  are  the  responsibility  of  the  custodian  committee  for 
the  RFC.  The  Test  Plan  is  addressed  when  the  “Recommended  for  Gray  Pages”  status  is  reported 
to  the  IGES  Project  Committee  by  the  custodian  committee’s  chairperson.  See  Section  3.3.1.  The 
Test  Plan  is  balloted  and  commented  upon  in  the  RFC  ballot  along  with  the  RFC  Form  itself. 
Comments  on  the  Test  Plan  will  be  handled  as  any  comment  on  the  RFC.  See  Section  3.3.4. 

Coordination  with  the  Gray  Page  Committee  for  review  of  the  Test  Plan  will  be  initiated  when 
comments  from  the  ballot  process  have  been  resolved  and  the  Plan  is  able  to  be  recommended  by 
the  custodian  committee.  The  Gray  Page  Committee  will  review  the  Test  Plan  and  make  com- 
ments. A Gray  Page  Test  Plan  Review  letter  will  be  issued  back  to  the  custodian  committee  and 
used  in  finalizing  the  Test  Plan. 

Within  the  custodian  committee,  attempts  will  likely  be  made  to  delegate  responsibility  for  the 
Test  Plan  to  the  author  of  the  RFC.  The  idea  here  is  to  encourage  the  person  or  persons  most  inter- 
ested in  the  RFC  to  see  that  Gray  Page  testing  is  addressed  in  a timely  manner,  with  the  optimum 
result  being  that  the  entity  never  receives  an  UNTESTED  designation 
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The  Test  Plan  is  to  describe  the  information  to  be  passed  and  the  details  of  the  test,  i.e.,  what  con- 
stitutes successful  exchange  of  the  information.  The  Test  Plan  will  be  structured  to  consist  of  one 
or  more  test  cases. 

Ideally,  the  Test  Plan  will  identify  the  individual  or  individuals  from  whom  commitments  have 
been  obtained  for  constructing  the  test  cases  and  carrying  out  the  testing.  If  feasible,  the  Test  Plan 
will  include  the  names  of  the  systems  to  be  used  in  the  test.  Based  on  the  commitments  obtained, 
the  Test  Plan  will  include  a schedule  to  allow  the  IGES  Project  Committee  to  judge  progress 
towards  its  completion. 


Custodian  Committee  Responsibilities  For  Gray  Page  Testing: 

For  each  RFC  requiring  Gray  Page  testing: 

1 . Originate  a proposed  Test  Plan  for  inclusion  along  with  the  RFC  Form  in  the  RFC  ballot. 

2.  Prepare  a recommended  Test  Plan  taking  into  account  the  results  of  the  RFC  ballot,  present 
this  to  the  Gray  Page  Committee  for  review,  and  act  on  the  results  of  the  review  to  finalize  the 
Plan. 

3.  Obtain  commitment  to  carry  out  the  Test  Plan,  and  prepare  a schedule  of  anticipated  activities 
accordingly. 

4.  Report  to  the  IGES  Project  Committee  concerning  approval  of  the  RFC  for  Gray  Page  testing. 

5.  Track  the  testing  activity  as  it  progresses. 

6.  Arrange  for  the  Gray  Page  Committee  to  review  the  test  results  against  the  finalized  Test  Plan. 

7.  Receive  the  Gray  Page  Testing  Review  letter  (see  below)  from  the  Gray  Page  Committee. 

8.  Archive  the  Test  Plan  and  individual  test  case  material  as  necessary  in  the  RFC  Folder. 

9.  Report  to  the  IGES  Project  Committee  concerning  approval  of  the  RFC  for  ECO. 


3.4.2  The  Gray  Page  Committee 

Following  its  review  of  the  test  results,  the  Gray  Page  Committee  will  issue  a Gray  Page  Testing 
Review  letter.  This  committee  is  a subcommittee  of  the  IGES  Project  Committee  (not  a Technical 
Committee  of  the  IPO  General  Assembly). 

The  review  of  the  Gray  Page  test  results  will  focus  on  the  adherence  of  the  testing  activities  to  the 
Test  Plan,  on  the  completeness  with  respect  to  the  test  cases  listed  in  the  Test  Plan,  and  on  the 
quality  of  the  individual  test  case  results. 

Following  its  review  of  the  test  results,  the  Gray  Page  Committee  will  issue  a second  Gray  Page 
Test  Review  letter  for  the  RFC  (as  in  Section  3.4.1;  the  first  concerned  the  review  of  the  final  Test 
Plan).  This  letter  will  make  a recommendation  as  to  whether  or  not  the  testing  for  the  RFC  was 
extensive  enough  and  successful  enough  to  support  removing  an  entity’s  UNTESTED  designa- 
tion. 


Gray  Page  Committee  Responsibilities  For  Gray  Page  Testing: 

1 . Review  each  recommended  Test  Plan  and  issue  a Gray  Page  Test  Plan  Review  letter. 

2.  Review  Gray  Page  test  results  for  each  RFC  requiring  Gray  Page  testing  and  issue  a Gray 
Page  Testing  Review  letter  to  the  IGES  Project  Committee  recommending  whether  or  not  the 
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testing  is  sufficient  to  remove  an  entity's  UNTESTED  designation. 

3.  The  Head  of  the  Gray  Page  Committee  will  report  regularly  to  the  IGES  Project  Committee 
concerning  its  activities. 


3.4.3  Oversight  Review  for  Gray  Page  Testing  Approval 

The  IGES  Project  Committee  performs  oversight  review  for  Gray  Page  testing  approval  on  each 
RFC  that  has  reached  “Recommended  For  Gray  Pages”  status  within  the  custodian  committee.  As 
given  in  Section  3.2.3,  the  oversight  review  is  initiated  by  the  report  of  the  custodian  committee 
chairperson  to  the  IGES  Project  Committee. 

The  report  will  contain  at  least  the  following: 

RFC  ballot  results,  ballot  comments,  and  their  resolution,  especially  concerning  the  pro- 
posed Test  Plan. 

Actions  taken  to  finalize  the  Test  Plan  as  a result  of  the  Gray  Page  Test  Plan  Review  letter 
Commitment  and  anticipated  schedule  for  carrying  out  the  Test  Plan. 

Options  for  the  IGES  Project  Committee  following  oversight  review  were  given  in  Section  3.2.3. 

RFC  Cover  Sheet  Information  Recorded  At  This  Stage: 

See  items  4 and  5,  Section  3.2.3. 

RFC  Actions  Taken  At  This  Stage: 

See  items  5,  6,  and  7,  Section  3.2.3. 


3.4.4  Existing  Gray  Page  Material  Recommendations 

For  these  entities,  responsibility  for  finalizing  the  Gray  Page  Test  Plan  lies  with  the  custodian 
committee  for  the  original  RFC.  However,  the  Gray  Page  Committee  will  assist  by  working 
actively  to  originate  a Test  Plan  for  each  entity  to  be  tested  that  will  be  presented  to  the  custodian 
committee  for  finalization.  The  Gray  Page  Committee  will  seek  to  identify  parties  willing  to  par- 
ticipate in  the  testing  of  an  entity,  and  will  work  with  those  parties  in  the  origination  of  the  Test 
Plan.  The  Test  Plan  will  be  presented  to  the  custodian  committee  for  finalization  along  with  a 
Gray  Page  Test  Plan  Review  letter  addressing  any  relevant  issues.  Other  procedures  remain  as  in 
Section  3.4.3  for  new  RFCs. 

In  view  of  the  large  number  of  entities  currently  designated  as  UNTESTED,  the  Gray  Page  Com- 
mittee is  encouraged  to  recruit  help  in  this  area. 

When  it  becomes  necessary  to  set  priorities  as  to  which  entities  to  address  first,  the  Gray  Page 
Committee  is  encouraged  to  take  direction  from  the  IGES  Project  Committee. 


3.5  The  Edit  Change  Order  (ECO)  Process 

The  Edit  Change  Order  (ECO)  is  the  mechanism  by  which  the  IGES  Editor  is  officially  informed 
of  the  content  of  a change  to  the  Specification,  and  also  authorized  to  make  the  change  to  the  mas- 
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ter  copy  of  the  Specification. 

Typically,  an  ECO  represents  the  culmination  of  work  on  an  RFC  that  encompasses  technical 
coordination,  balloting,  resolution  of  comments,  and  achievement  of  final  technical  and  editorial 
consensus.  In  these  cases,  the  ECO  is  essentially  the  RFC  Form  as  it  existed  when  the  RFC 
reached  “Recommended  for  Gray  Pages”  or  “Recommended  For  Update”  status  in  the  custodian 
committee.  In  other  cases,  an  ECO  originates  within  the  IGES  Project  Committee  itself  and  con- 
cerns editorial  changes  to  the  Specification 

ECOs  are  proposed  to  and  approved  by  the  IGES  Project  Committee.  An  ECO  may  be  proposed 
to  the  IGES  Project  Committee  by  either  a chairperson  of  a custodian  committee  for  an  RFC,  by 
the  Chairperson  of  the  Gray  Page  Committee,  or  by  a voting  member  of  the  IGES  Project  Com- 
mittee on  behalf  of  the  entire  IGES  Project  Committee.  In  particular,  the  IGES  Editor  can  propose 
an  ECO  on  behalf  of  the  entire  committee. 


3.5.1  The  Makeup  of  an  ECO 

An  ECO  consists  of  an  RFC  Cover  Sheet  together  with  the  content  of  the  change  being  authorized 
to  the  Specification. 

The  change  content  is  presented  in  its  “integrated  form,”  i.e.,  all  parts  of  the  Specification  affected 
by  the  change  are  accurately  depicted  as  they  will  appear  after  the  change  has  been  made.  Tempo- 
rary entity  type  and  form  numbers  have  been  replaced  by  actual  numbers.  Logically  complete  por- 
tions of  the  Specification  are  depicted. 

Since  each  RFC  is  balloted  in  its  integrated  form,  the  ECO  is  equivalent  to  the  proposed  change 
portion  of  the  RFC;  however,  editorial  changes  made  after  balloting  will  require  manual  identifi- 
cation and  Editor  notifying. 

The  Cover  Sheet  contains  the  necessary  administrative  information  for  the  ECO.  See  Appendix  B 
for  an  example  of  the  RFC  Cover  Sheet. 

ECOs  are  numbered  in  increasing  order,  although  not  necessarily  sequentially.  Sequential  “issue” 
versions  (“A,”  “B,”  “C,”  etc.)  of  an  ECO  can  exist;  for  example,  RFCs  assigned  “Recommended 
for  Gray  Pages”  status  will  result  in  an  ECO  to  direct  the  IGES  Editor  to  insert  the  entity  with  an 
UNTESTED  designation.  If  testing  is  completed  successfully  before  the  IGES  Editor  takes  action 
on  the  ECO,  a new  version  may  be  issued  to  remove  the  UNTESTED  designation;  however,  usu- 
ally a new  ECO  number  will  be  created. 

All  ECOs  exist  officially  in  both  paper  and  electronic  form.  They  are  archived  by  the  Change 
Control  Secretary  in  their  paper  form.  All  issue  versions  are  archived.  In  their  electronic  form, 
they  are  accepted  and  managed  as  electronic  files  by  the  IGES  Editor  for  integration  into  the 
Specification. 


3.5.2  Oversight  Review  for  ECO  Approval 

The  IGES  Project  Committee  performs  oversight  review  on  each  proposed  ECO.  It  is  presumed 
that  the  change  content  of  each  proposed  ECO  exists  in  both  paper  and  electronic  form. 

As  given  in  Section  3.2.3,  when  the  proposed  ECO  is  for  an  RFC  that  has  reached  “Recom- 
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mended  for  Gray  Pages”  or  “Recommended  for  Update”  status  in  custodian  committee,  the  over- 
sight review  is  initiated  by  a report  containing  at  least  the  following: 

1.  RFC  ballot  results,  and  ballot  comments  and  their  resolution. 

2.  Gray  Page  testing  (if  it  was  required). 

3.  The  state  of  the  consensus  agreement  between  the  custodian  committee  and  the  IGES  Editor 
concerning  the  change  content  of  the  ECO. 

Options  for  the  IGES  Project  Committee  following  oversight  review  were  given  in  Section  3.2.3. 

If  the  oversight  review  results  in  an  ECO  approved  or  conditionally  approved,  the  “Approval  For 
Release”  signatures  on  the  RFC  Cover  Sheet  must  be  obtained  from  the  presenter  of  the  ECO  and 
from  the  Project  Manager;  the  cover  sheet  and  a final  form  of  the  ECO  will  be  supplied  to  the 
IGES  Editor.  For  approved  ECOs,  the  signatures  can  be  obtained  immediately,  the  Cover  Sheet 
can  be  attached  to  the  RFC  as  presented,  and  these  can  be  turned  over  to  the  IGES  Editor.  For 
ECOs  approved  conditionally,  the  necessary  changes  should  be  minor  enough  that  the  presenter  of 
the  RFC  can  sign  the  RFC  Cover  Sheet  and  attach  it  to  a marked-up  copy  of  the  RFC  presented 
for  oversight  review.  The  signature  of  the  Project  Manager  is  added  later  after  the  editorial 
changes  have  been  made,  and  this  signature  denotes  that  the  RFC  is  in  final  form  and  is  ready  to 
be  supplied  to  the  IGES  Editor.  In  rare  cases,  editorial  changes  resulting  from  oversight  review 
may  be  extensive  enough  to  warrant  generation  of  an  updated  version  of  the  ECO  before  the 
Cover  Sheet  can  be  signed. 

When  the  proposed  ECO  is  being  presented  by  a voting  member  of  the  IGES  Project  Committee 
on  behalf  of  the  entire  Committee,  a report  will  be  made  summarizing  the  reasoning  and  justifying 
the  editorial  change.  This  type  of  ECO  ordinarily  will  be  initiated  by  the  IGES  Editor  to  fix  gram- 
mar or  typographical  errors  of  a non-technical  nature.  The  IGES  Project  Committee  will  either 
accept  or  reject  the  proposed  ECO  and  record  this  in  the  minutes. 

Consideration  and  approval  of  ECOs  constitutes  official  business  of  the  IGES  Project  Committee. 
RFC  Cover  Sheet: 

1.  The  presenter  of  the  RFC  fills  out  and  signs  the  RFC  Cover  Sheet  and  supplies  the  Project 
Manager  with  the  paper  copy  of  the  RFC. 

2.  The  Project  Manager  signs  the  RFC  Cover  Sheet. 

ECO  Actions  Taken: 

1.  The  Project  Manager  passes  the  ECO  to  the  Change  Control  Secretary  for  archiving,  supplies 
the  Editor  with  a paper  copy  of  the  ECO,  and  verifies  that  the  Editor  has  an  electronic  copy  of 
the  integrated  form  of  the  RFC. 

2.  The  Change  Control  Secretary  archives  a paper  copy  of  the  ECO. 

3.  The  Editor  manages  the  electronic  form  of  the  ECO. 
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4.0  The  Process  for  Approving  Major  Changes  to  the  Specifi- 
cation 

4.1  New  Versions  of  the  Specification 

1.  The  IGES  Project  Committee  will  consider  a motion  to  approve  a new  version  of  the  Specifi- 
cation. Any  member  of  the  Committee  may  initiate  this  motion,  but  the  IGES  Editor  is  most 
likely  to  do  so  following  a “reading  session”  by  members  of  the  IGES  Editorial  Committee 
and  the  IGES  Project  Committee.  The  initiator  will  prepare  an  RFC  for  tracking  purposes  and 
will  obtain  a number  from  the  Change  Control  Secretary. 

2.  If  the  motion  passes,  the  IGES  Project  Committee  will  assign  “Approved  for  Ballot”  immedi- 
ately. The  IGES  Project  Committee  is  the  custodian  committee  for  this  RFC,  and  all  Technical 
Committees  of  the  IPO  are  considered  “joint-interest”  committees.  The  RFC  will  not  require 
Gray  Page  Testing. 

3.  A draft  of  the  proposed  new  version  of  the  Specification  will  be  prepared  and  distributed  at  the 
next  meeting  of  the  IPO  to  minimize  mailing  costs.  The  “draft”  status  will  be  marked  clearly. 
An  announcement  will  be  made  to  remind  members  to  complete  a ballot  request  form  if  they 
currently  are  not  a member  of  the  Ballot  Group  and  wish  to  vote. 

4.  Members  of  the  Ballot  Group  will  receive  a mail  ballot  that  concerns  only  the  RFC  initiated  in 
step  2 concerning  the  question  of  approving  the  new  version  of  the  Specification.  (No  other 
RFCs  may  be  included  with  this  ballot.)  This  ballot  also  will  include  instructions  for  receiving 
a copy  of  the  proposed  new  version  of  the  Specification  if  one  was  not  obtained  at  the  IPO 
meeting. 

5.  The  mail  ballot  is  handled  according  to  procedures  in  Section  3.3.2;  the  response  deadline 
shall  allow  a minimum  of  two  months  for  review. 

6.  Comments  on  the  mail  ballot  will  be  handled  by  the  IGES  Project  Committee  or  distributed  to 
the  most  qualified  joint-interest  Technical  Committee  for  handling  according  to  procedures  in 
Section  3.3.4.  Due  to  prior  review  of  technical  changes  in  the  RFC  process,  it  is  assumed  that: 
1)  most  comments  will  be  editorial,  and  2)  all  comments  will  be  resolvable.  (Step  8 below 
deals  with  comment  resolution  requiring  reballot.)  Technical  comments  concerning  areas  of 
the  Specification  that  did  not  change  from  the  prior  version,  or  any  comments  duplicating  pre- 
viously classified  “non-persuasive”  comments  are  inappropriate  and  will  be  classified  “non- 
persuasive.” 

7.  If  resolving  comments  requires  making  changes,  each  joint-interest  committee  will  contact  the 
IGES  Editor  to  amend  the  master  copy  of  the  proposed  new  Specification,  and  return  the 
tracking  RFC  to  the  IGES  Project  Committee  with  the  “Approved  for  Update”  status  assigned. 
If  this  is  impossible,  the  chairperson  of  the  joint-interest  committee  should  obtain  assistance 
from  the  IGES  Project  Committee  to  resolve  the  comment  causing  the  difficulty.  In  the  event 
that  persuasive/technical  comment(s)  cause  the  need  to  reballot,  a new  version  of  the  tracking 
RFC  will  be  balloted,  but  it  will  refer  only  to  the  specific  areas  needing  reballoting — the  entire 
Specification  will  not  be  reballoted.  Any  comments  on  other  subjects  are  inappropriate  and 
will  be  classified  “non-persuasive.” 

8.  Following  receipt  of  “Approved  for  Update”  status  from  all  joint-interest  committees,  the 
IGES  Project  will  perform  oversight  review  of  the  comment  dispositions;  in  most  cases, 
this  will  be  at  an  interim  meeting  due  to  the  time  required.  Following  successful  review,  the 
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IGES  Project  Committee  will  issue  an  ECO  to  the  IGES  Editor  directing  the  release  of  the 
new  version  of  the  Specification.  The  new  version  of  the  Specification  will  be  submitted  to 
ANSI  as  a proposed  American  National  Standard  according  to  procedures  in  the  IGES/PDES 
Organization  Reference  Manual  (available  from  the  IPO  Office  or  at  IPO  meetings). 

The  minutes  of  the  IGES  Project  Committee  and  of  all  the  joint-interest  Technical  Committees, 
and  all  the  required  paperwork  connected  with  approval,  balloting,  and  comment  resolut  f the 
tracking  RFC  initiated  above,  constitute  official  business  of  the  IGE/PDES  Organization. 


4.2  Application  Protocols 

In  addition  to  IGES  itself,  this  document  also  pertains  to  the  related  “Application  Protocol”  addi- 
tions. The  following  apply: 

1.  The  IGES  Project  Committee  will  consider  a motion  from  the  chairperson  of  the  application 
protocol’s  technical  committee  to  approve  an  application  protocol.  The  initiator  will  prepare 
an  RFC  for  tracking  purposes  and  will  obtain  a number  from  the  Change  Control  Secretary. 

2.  If  the  motion  passes,  the  IGES  Project  Committee  will  assign  “Approved  for  Ballot”  immedi- 
ately. The  application  protocol’s  technical  committee  is  the  custodian  committee  for  this  RFC. 
The  RFC  will  not  require  Gray  Page  testing. 

3.  A draft  of  the  proposed  application  protocol  will  be  prepared  and  distributed  at  the  next  meet- 
ing of  the  IPO  to  minimize  mailing  costs.  The  “draft”  status  will  be  marked  clearly.  An 
announcement  will  be  made  to  remind  members  to  complete  a ballot  request  form  if  they  cur- 
rently are  not  a member  of  the  Ballot  Group  and  wish  to  vote. 

4.  Members  of  the  Ballot  Group  will  receive  a mail  ballot  concerning  the  question  of  approving 
the  Application  Protocol  (other  RFCs  may  be  included  with  this  ballot).  This  ballot  also  will 
include  instructions  for  receiving  a copy  of  the  proposed  application  protocol  if  one  was  not 
obtained  at  the  IPO  meeting. 

5.  The  mail  ballot  is  handled  according  to  procedures  in  Section  3.3.2;  the  response  deadline 
shall  allow  a minimum  of  one  month  for  review. 

6.  Comments  on  the  mail  ballot  will  be  handled  according  to  procedures  in  Section  3.3.4;  due  to 
prior  review  of  any  technical  changes  needed  by  the  application  protocol  in  the  RFC  process, 
it  is  assumed  that:  1)  most  comments  will  be  editorial,  and  2)  all  comments  will  be  resolvable. 

7.  If  resolving  comments  requires  making  changes,  the  application  protocol’s  technical  commit- 
tee will  amend  the  master  copy  of  the  proposed  application  protocol  and  return  the  tracking 
RFC  to  the  IGES  Project  Committee  with  the  “Approved  for  Update”  status  assigned.  If  this  is 
impossible,  the  chairperson  of  the  joint-interest  committee  should  obtain  assistance  from  the 
IGES  Project  Committee  to  resolve  the  comment  causing  the  difficulty.  In  the  event  that  per- 
suasive, technical  comment(s)  cause  the  need  to  reballot,  a new  version  of  the  tracking  RFC 
will  be  balloted,  but  it  will  refer  only  to  the  specific  areas  needing  reballoting — the  entire 
application  protocol  will  not  be  reballoted.  Any  comments  on  other  subjects  are  inappropriate 
and  will  be  classified  “non-persuasive.” 

8.  Following  receipt  of  “Approved  for  Update”  status  from  the  application  protocol’s  technical 
committee,  the  IGES  Project  will  perform  oversight  review  of  the  comment  disposition.  Fol- 
lowing successful  review,  the  IGES  Project  Committee  will  issue  an  ECO  to  the  IGES  Editor 
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directing  the  release  of  the  application  protocol.  The  minutes  of  the  IGES  Project  Committee 
and  of  the  application  protocol’s  technical  committee,  and  all  the  required  paperwork  con- 
nected with  approval,  balloting,  and  comment  resolution  of  the  tracking  RFC  initiated  above, 
constitute  official  business  of  the  IGES/PDES  Organization. 


5.0  The  Appeals  Process 

The  process  of  maintaining  and  changing  the  Initial  Graphics  Exchange  Specification  is  based 
upon  the  concept  of  “consensus”  (i.e.,  substantial  agreement  among  most  of  those  concerned;  see 
section  1.1).  These  procedures  assure  that 

• serious  proposals  to  change  the  Specification,  as  well  as  any  comments  concerning  such 
proposals,  will  be  given  the  most  careful  consideration  possible  by  at  least  two  groups  of 
qualified  persons  (i.e.,  the  custodian  technical  committee,  and  the  IGES  Project  Commit- 
tee), and 

• the  results  of  this  consideration  will  be  documented  completely  and  communicated  unam- 
biguously to  those  involved. 

In  most  cases,  informal  resolution  of  disagreements  in  the  technical  committee  meeting  are  the 
most  effective  and  efficient  way  to  solve  problems.  Ideally,  consensus  will  be  reached  via  com- 
promise followed  by  unanimous  agreement;  however,  compromise  can  be  impossible  in  technical 
issues  having  mutually  exclusive  alternatives.  When  this  happens,  the  committee’s  Chairperson 
ordinarily  puts  the  matter  to  a vote,  and  exercises  discretion  to  determine  if  the  vote  is  sufficiently 
one-sided  to  qualify  as  “consensus”  (i.e.,  a simple  majority  is  not  enough);  if  it  is,  the  opinion  of 
the  majority  shall  prevail.  In  spite  of  this,  anyone  holding  the  minority  opinion  who  is  or  will  be 
materially  and  adversely  affected  by  the  outcome  has  the  right  to  pursue  the  formal  process 
described  below  to  appeal  the  decision. 


5.1  Definition  of  Appellants 

1 . Any  RFC  author  whose  RFC  is  assigned  “Cancelled”  status  by  the  custodian  technical  com- 
mittee of  the  IPO  has  the  right  of  appeal  to  the  IGES  Project  Committee  if  the  matter  has 
been  discussed  and  cannot  be  resolved  within  the  custodian  technical  committee  meeting. 

2.  All  commentors  participating  in  the  RFC  ballot  process  who  disagree  with  the  classification  of 
their  comment(s)  as  “non-persuasive”  have  the  right  of  appeal  to  the  IGES  Project  Committee 

the  matter  has  been  discussed  and  cannot  be  resolved  within  the  custodian  Technical  Com- 
mittee meeting. 


5.2  Appeals  procedure 

To  appeal,  send  photocopies  of  original  comment(s)  and  the  IGES  RFC  Comment  Disposition 
Form  (if  received)  to  the  IGES  Project  Manager  with  a signed  statement  indicating  the  area  of  dis- 
agreement and  the  outcome  that  would  satisfy  the  appellant’s  concerns.  Appellants  will  be  sched- 
uled on  the  agenda  of  the  next  IGES  Project  Committee  meeting  to  discuss  the  situation;  after 
discussion,  the  Committee  will  propose  and  vote  on  action  to  resolve  the  matter.  Appellants  who 
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continue  to  feel  they  are  adversely  and  materially  affected  may  appeal  to  the  IPO  Chairperson  for 
binding  arbitration.  Refer  to  the  IGES/PDES  Organization  Reference  Manual  (re-published  for 
each  IPO  meeting)  for  more  information. 


6.0  IGES  Change  Tracking 

Presently,  the  IGES  Change  Control  Secretary  manages  IGES  Change  Tracking.  RFC  status  at 
any  point  in  time  is  available  from  a database  containing  the  electronic  master  of  the  RFC  cover 
sheets.  In  addition,  a summary  “tracking  worksheet”  can  be  produced  as  part  of  the  process  of 
managing  the  RFC  cover  sheets.  The  electronic  cover  sheet  file  is  available  on  a computer  at  the 
IPO  meetings  so  Technical  Committee  Chairpersons  can  make  updates  if  desired.  (The  process  is 
simple  enough  that  even  those  who  are  not  trained  in  the  hypertext  application  used  can  succeed.) 
There  is  also  a procedural  diagram  available  interactively.  Copies  of  some  of  these  screens  appear 
in  a companion  document  referenced  in  Preface  footnote  1 . 

In  the  future,  it  is  hoped  that  the  entire  RFC  process  will  be  managed  using  a database,  thereby 
increasing  both  the  ability  to  share  information  and  the  ease  of  keeping  it  up  to  date.  For  now, 
many  people  who  are  participants  in  this  process  have  access  to  electronic  mail.  In  particular,  any- 
thing sent  via  e-mail  to  the  IGES  Change  Control  Secretary  can  be  automatically  “exploded”  to  a 
mailing  list  for  wider  distribution.  The  Internet  World  Wide  Web  (see  Preface  for  URLs)  is  used  to 
provide  the  Project  with  a list  of  the  active  RFCs  and  the  ECOs  as  they  are  approved  for  the  next 
IGES  version. 

Information  in  this  section  will  be  expanded  as  procedures  connected  with  IGES  Change  are 
refined  during  the  application  of  other  procedures  in  this  document. 


7.0  Informal  Forums  for  IGES  Issues,  Analyses,  etc. 

As  discussed  in  prior  sections  of  this  document,  potential  RFC  authors  who  identify  a problem  to 
be  solved  are  expected  to  also  identify  several  proposed  alternatives  to  solve  it  either  by  them- 
selves or  by  consultation  with  technical  experts  in  the  area  of  concern.  In  the  event  that  at  least 
one  apparently  useful  solution  cannot  be  identified,  the  formal  RFC  process  should  not  be  initi- 
ated; the  potential  RFC  author  should  pursue  the  following  suggestions  first: 

Check  the  IGES  Recommended  Practices  Guide  to  see  if  the  problem  situation  is 
addressed.  In  many  instances,  a Recommended  Practice  is  established  prior  to  or  concur- 
rently with  an  in-process  RFC  (this  happens  because  Proposed  Recommended  Practices 
can  be  put  in  place  very  quickly  compared  to  the  formal  RFC  process).  In  addition,  such 
checking  may  indicate  a Proposed  Recommended  Practice  is  a more  appropriate  way  to 
deal  with  the  situation  involved,  and  authoring  one  is  much  easier  than  an  RFC.  Further- 
more, the  possibility  of  quick  approval  of  a Recommended  Practice  means  a policy  to 
solve  a problem  can  be  in  place  sooner,  thereby  minimizing  continued  harm  from  the 
problem  as  well  as  quantifying  the  value  of  a formal  RFC  solution.  Consult  the  Chairper- 
son of  the  IGES  Implementors  Committee  for  more  information. 
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Attend  a meeting  of  the  Technical  Committee  of  the  IPO  whose  area  of  expertise  seems 
appropriate  to  address  the  area  of  concern  (e.g.,  discuss  a mathematics  issue  with  the 
Geometry  Committee).  If  unsure  of  which  committee  is  most  appropriate,  start  with  the 
Implementors’  Committee  due  to  their  familiarity  with  the  software  systems  which  actu- 
ally perform  the  exchange  processing.  At  the  meeting,  someone  is  bound  to  offer  informa- 
tion that  will  help  in  making  a decision  to  write  an  RFC  or  drop  the  matter.  If  not,  it  is 
likely  that  an  ad  hoc  subcommittee  will  be  formed  in  an  attempt  to  deal  with  the  problem. 
In  the  past,  this  method  has  been  the  most  successful  in  dealing  promptly  with  problems 
that  have  no  apparent  solution.  Afterward,  the  results  obtained  should  indicate  if  the  next 
action  should  be  a Proposed  Recommended  Practice,  an  RFC,  or  both  at  once. 

Ask  to  speak  at  the  plenary  session  of  the  IPO  General  Assembly.  Again,  someone  is 
likely  to  offer  suggestions  either  immediately  or  afterwards.  If  reluctant  to  speak  publicly, 
request  the  IGES  Project  Manager  to  bring  up  the  issue  for  you  or  submit  an  anonymous 
request. 

Write  a paper  and  distribute  it  for  comments.  In  the  past,  the  RFC  process  included  a 
“Change  Analysis”  paper  that  identified  a problem,  but  not  always  its  solution.  Efficiency 
considerations  dictated  dropping  this  step  as  a formal  requirement  because  most  authors 
were  found  to  have  a solution  in  mind  and  could  therefore  go  straight  to  the  RFC-author- 
ship  step.  Nothing  in  this  procedure  prohibits  this  type  of  paper;  in  fact,  this  method  is  pre- 
ferred to  the  idea  of  authoring  an  RFC  with  a useless  solution  in  an  attempt  to  get  feed- 
back. Such  papers  may  be  distributed  at  the  IPO  meetings.  Their  availability  can  be 
announced  in  the  daily  newsletter  by  requesting  this  at  the  IPO  meeting  office.  Other  dis- 
tribution options  include  sending  the  paper  out  with  specific  Technical  Committee  meeting 
minutes  (consult  Chairperson  of  the  relevant  Technical  Committee),  or  requesting  the 
paper  be  included  in  the  mail  ballot  to  the  Ballot  Group  (consult  the  IGES  Project  Man- 
ager). 

Pursuing  the  above  suggestions  will  save  both  time  and  unnecessary  effort  for  everyone  involved 
in  the  RFC  process.  Past  experience  convincingly  demonstrates  that  RFCs  containing  incomplete 
or  ineffective  solutions  to  problems  have  consumed  tremendous  resources  by  their  repeated  itera- 
tions through  the  process.  Spending  extra  effort  initially  on  informal  research  will  pay  future  div- 
idends in  the  form  of  reduced  rework,  decreased  processing  time,  and  increased  acceptance. 
Everyone  will  recognize  and  appreciate  an  effort  to  prepare  complete,  high-quality  work. 


8.0  Step-by-Step  User  Guide  to  the  RFC  Process 

This  section  documents  the  entire  RFC  Process  in  a straightforward,  step-by-step  manner.  These 
steps  are  consistent  with  the  detailed  description  of  the  process  appearing  in  prior  sections.  The 
necessary  simplification  may  not  cover  all  details,  particularly  if  problems  occur  with  a specific 
RFC — in  this  case,  refer  to  prior  applicable  sections  for  more  information.  The  steps  are  written  in 
a short,  direct  style  and  are  organized  into  a checklist  that  may  be  especially  useful  to  new  RFC 
authors. 

Section  8.1  covers  processing  of  “normal”  priority  RFCs;  i.e.,  RFCs  submitted  more  than  six 
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months  prior  to  the  anticipated  publication  date  of  the  next  version  of  the  Specification.  RFCs  in 
this  category  may  cover  any  appropriate  subject  because  there  is  ample  time  for  consideration  and 
work  to  resolve  any  problems.  Potential  authors  should  be  aware  that  controversial  or  com- 
plicated RFCs  have  required  up  to  two  years  for  completion  of  processing. 

Section  8.2  covers  processing  of  “expedited”  priority  RFCs;  i.e.,  RFCs  submitted  less  than  six 
months  prior  to  the  anticipated  publication  date  of  the  next  version  of  the  Specification.  Expedit- 
ing refers  to  getting  the  RFC  from  concept  to  ballot  quickly.  It  is  very  difficult  to  speed  up  the  sub- 
sequent ballot  and  comments  resolution  process,  but  those  processes  also  are  likely  to  be  faster  if 
the  limitations  below  are  observed.  RFCs  in  this  category  are  limited  in  subject  and  content  due  to 
the  limited  time  frame.  In  general,  these  limitations  apply: 

• The  author  has  researched  the  problem  prior  to  the  meeting  to  identify  both  solutions  and 
support  from  those  who  may  be  affected,  and  has  prepared  this  information  in  paper  form 
to  facilitate  immediate  committee  discussion. 

• The  Technical  Committee  to  be  assigned  as  custodian  should  be  obvious;  there  should  be 
no  joint-interest  committee  involvement. 

• Both  the  problem  and  its  proposed  solution  should  be  clear,  obvious,  and  non-controver- 
sial  (e.g.,  adding  a new  property  is  a good  candidate;  changing  a complex  entity  like  the 
Trimmed  Surface  is  not). 

• The  entire  process  should  be  started  early  in  the  week  at  an  IPO  meeting  so  that  the  elec- 
tronic master  of  the  Specification,  the  designated  document  and  IGES  processors  for  the 
Specification,  the  IGES  Editorial  Committee,  and  the  IGES  Change  Control  Secretary  all 
are  available  to  enable  production  of  the  “ballot-ready”  RFC. 

Although  there  are  no  guarantees  of  success,  following  the  Section  8.2  steps  will  maximize 
the  chance  for  the  earliest  possible  completion  of  RFCs  suitable  for  expediting. 
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8.1  Normal  processing 


1 . Identify  problem. 

Discuss  problem  with  others  who  are  qualified  to  propose  solutions.  Based  on 
discussion,  determine  if  a Proposed  Recommended  Practice  is  appropriate  in 
addition  to  or  instead  of  an  RFC.  Refer  to  the  IGES  Recommended  Practices 
Guide  for  procedures  to  propose  a Recommended  Practice. 

2.  Initial  Prepara- 
tion 

Assuming  an  RFC  should  be  proposed,  obtain  a number  from  the  IGES 

Change  Control  Secretary  by  submitting  a paper  RFC  form  containing  a short 
statement  of  the  problem  and  proposed  solution(s).  Copy  the  RFC  skeleton 
file  and  complete  author  information,  title,  problem  statement,  and  proposed 
solution.  Submit  electronically  as  defined  in  3.2.4.  Alternatively,  prepare  a 
similar-appearance  form  (see  Appendix  B of  this  document)  with  a word  pro- 
cessor, print,  and  submit  the  printed  output.  (Note:  if  not  using  the  designated 
Specification  document  processor,  this  work  will  have  to  be  redone  before  the 
RFC  is  eligible  for  mail  ballot,  so  it  may  be  better  to  use  the  copying  method 
initially.)  When  accepted  by  the  Secretary,  RFC  is  now  “official”;  it  receives 
Unassigned  status.  Use  the  RFC  number  for  entity  type  or  form  numbers  (see 
section  3.2.1). 

3.  Routing  RFC 

RFC  will  be  forwarded  to  the  IGES  Project  Committee  for  assignment  to  a 
custodian  Technical  Committee  and  determination  of  the  need  for  Gray  Page 
Testing.  RFC  authors  may  attend  the  IGES  Project  Committee  meeting  if 
desired.  When  assigned  to  a custodian,  RFC  has  Open  status. 

4.  Creating  Fig- 
ure^) 

If  any  illustrations  are  required,  prepare  them  as  IGES  files  now.  Choose  full 
page  (portrait)  or  half  page  (landscape).  File  must  be  1-to-l  scale.  Minimum 
text  height  is  5 mm  (0.2  inches).  Explanatory  annotation  should  be  6mm  (0.25 
inches).  Include  only  illustration,  with  no  captions  or  outside  border  lines.  Use 
only  2D  entities  in  the  X-Y  plane  if  possible.  Use  one  file  for  each  illustration. 
Use  ASCII  (non-compressed).  Save  on  floppy  disk  and  label  with  name,  RFC 
number,  operating  system,  and  density.  Obtain  advance  approval  from  IGES 
Editor  if  non-standard  illustrations  (e.g.,  photos)  are  desired. 

5.  Sponsoring  RFC 

RFC  author  should  attend  meeting  of  the  custodian  Technical  Committee  to 
discuss  the  RFC  and  identify  level  of  committee  support.  If  the  author  does 
not  attend  and  the  committee  feels  it  cannot  continue,  RFC  receives  Tabled 
status  until  continuation  is  possible;  otherwise,  the  RFC  is  discussed  and  pos- 
sibly amended.  If  committee  rejects  RFC,  and  author  agrees  to  withdraw  it, 

RFC  receives  Withdrawn  status  and  process  ends.  If  committee  rejects  RFC 
and  author  refuses  to  withdraw  it,  RFC  receives  Canceled  status;  author  may 
appeal  to  IGES  Project  Committee.  If  committee  accepts  RFC,  it  will  retain 
Open  status  while  the  author  completes  the  next  step. 

6.  Integrating  RFC 

Prepare  “integrated  electronic  form”  of  the  RFC  to  make  it  “ballot-ready.” 
Obtain  electronic  masters  of  the  RFC  form  and  the  appropriate  section  of  the 
Specification  from  the  IGES  Editorial  Committee;  these  will  be  in  the  input 
format  of  designated  document  processor  for  the  Specification  (currently 
IATeX).  Edit  as  required.  If  using  illustrations,  process  using  designated  IGES 
post-processor  for  the  Specification  (see  section  3.2.4).  Print  copies  of  RFC 
and  IGES  files  for  review  by  the  IGES  Editorial  Committee.  After  review, 
make  corrections  as  required  to  electronic  input  and  reprint.  Save  on  floppy 
disk  (see  rules  in  step  4). 
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7.  Promoting  RFC 

Author  returns  to  custodian  Technical  Committee  meeting  with  the  “inte- 
grated electronic  form”  RFC  and  paper  copies  which  have  been  reviewed  and 
approved  by  the  IGES  Editorial  Committee.  If  custodian  committee  decides 
RFC  must  be  significantly  changed,  steps  5,  6,  and  7 are  repeated  until  satis- 
factory. When  custodian  committee  accepts  RFC  (or  makes  minor  changes), 
RFC  receives  Recommended  for  Ballot  status;  custodian  committee  chair- 
person delivers  RFC  to  the  IGES  Project  Committee  for  oversight  approval. 

8.  Project  Review 

IGES  Project  Committee  meets  to  review  RFCs  having  Recommended  for 
Ballot  status;  author  may  attend  the  meeting.  If  RFC  meets  “ballot-ready” 
requirements,  RFC  receives  Approved  for  Ballot  status.  IGES  Project  Com- 
mittee delivers  RFC  to  the  IGES  Ballot  Coordinator;  otherwise,  RFC  receives 
Reviewed  status  and  is  returned  to  step  6. 

9.  Ballot  RFC 

RFC  is  considered  by  members  of  the  IGES  Ballot  Group.  Ballot  results  and 
comments  from  the  voting  process  are  returned  to  the  IGES  Project  Commit- 
tee; RFC  receives  Balloted  status.  Any  RFC  receiving  only  “Approve”  votes 
and  no  comments  receives  ECO  status.  If  Gray  Page  Testing  is  required  but 
not  completed,  the  entity  receives  untested  designation;  otherwise,  it  becomes 
part  of  the  Specification.  In  most  cases,  disapprovals  and  comments  will 
occur;  these  are  forwarded  to  the  RFC  author.  In  addition,  they  are  separated 
into  distinct  thoughts,  entered  into  a comments  database,  and  printed  on  Com- 
ment Disposition  Forms  for  delivery  to  the  Chairperson  of  the  custodian  Tech- 
nical Committee.  All  ballot  comments  must  be  considered  and  resolved. 

10.  Comment  han- 
dling 

Between  IPO  meetings,  RFC  author  personally  contacts  each  commentor  in 
an  attempt  to  resolve  their  comments  before  the  next  meeting;  ordinarily,  this 
succeeds  for  minor  objections  and  the  author  amends  the  integrated  form  RFC 
and  prints  new  copies.  If  the  author  does  not  succeed  in  resolving  all  com- 
ments, the  comments  will  be  handled  at  the  next  IPO  meeting.  The  author  is 
responsible  for  reporting  all  results  of  attempted  comment  resolution  to  the 
IGES  Change  Control  Secretary. 

1 1 . TC  review 

Custodian  Technical  Committee  meets  to  review  advance  comment  resolution 
by  RFC  author  and  to  handle  unresolved  comments.  The  Comment  Disposi- 
tion Form  (as  printed  from  the  comment  database)  must  be  used  to  document 
comment  resolution.  If  comment  resolution  causes  significant  editorial 
changes,  review  them  with  the  IGES  Editorial  Committee.  If  comment  resolu- 
tion identifies  that  the  RFC  cannot  be  amended,  committee  decides  if  salvage 
should  be  attempted;  if  so,  RFC  receives  Open  status  and  process  returns  to 
step  3.  The  author  will  be  asked  to  withdraw  an  unsalvageable  RFC;  if  author 
agrees,  RFC  receives  Withdrawn  status  and  process  ends.  If  author  refuses  to 
withdraw  it,  RFC  receives  Cancelled  status;  author  may  appeal  to  IGES 

Project  Committee.  If  comment  resolution  causes  change  in  technical  intent, 
RFC  receives  Recommended  for  Ballot  status  and  process  returns  to  step  8; 
otherwise,  RFC  receives  Recommended  for  Gray  Pages  status  (if  testing 
required,  but  not  completed)  or  Recommended  for  Update  status  (if  testing 
is  successfully  completed).  Results  are  delivered  to  the  IGES  Project  Commit- 
tee. 
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□ 12.  Project  review 

IGES  Project  Committee  meets  to  review  RFCs  having  Recommended  for 
Gray  Pages  or  Recommended  for  Update  status.  Minor  editorial  changes 
may  occur  during  review.  If  review  is  unsatisfactory,  RFC  receives  Reviewed 
status  and  process  returns  to  step  11.  If  review  is  satisfactory,  RFC  receives 
ECO  status  with  a directive  to  update  the  Specification  as  appropriate.  RFC  is 
delivered  to  the  IGES  Change  Control  Secretary  for  archiving.  Secretary  for- 
wards RFC  Cover  Sheet  and  “integrated  electronic  form”  of  RFC  to  IGES 
Editor  upon  completion  of  integrating  minor  editorial  changes  made  in  steps 

11  or  12  which  have  not  been  integrated  due  to  time  constraints. 

□ 13.  Incorporation 

by  Editor 

IGES  Editor  uses  ECO  to  update  master  copy  of  Specification  using  “inte- 
grated electronic  form”  of  RFC  as  part  of  document  management  procedure. 
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8.2  Expedited  processing 


1.  Identify  problem 

Discuss  problem  with  others  who  are  qualified  to  propose  solutions.  Based  on 
discussion,  determine  if  a Proposed  Recommended  Practice  is  appropriate  in 
addition  to  or  instead  of  an  RFC.  Refer  to  the  IGES  Recommended  Practices 
Guide  for  procedures  to  propose  a Recommended  Practice.  Before  continuing, 
you  should  be  certain  there  is  support  in  the  Technical  Committee  which  is  the 
obvious  custodian,  otherwise,  expediting  will  be  fruitless. 

2.  Integrating  RFC 

Assuming  an  RFC  should  be  proposed,  prepare  the  “integrated  electronic 
form”  immediately.  Schedule  time  on  one  of  the  IPO  office  computers.  Access 
the  electronic  masters  for  both  the  RFC  form  and  the  area  of  the  Specification 
affected  by  the  proposed  change.  Since  no  number  is  assigned,  assign  a tem- 
porary number  based  on  the  initials  in  your  name  prefixed  by  a number  begin- 
ning at  1 (incremented  for  each  RFC  if  you're  trying  to  expedite  more  than 
one;  e.g.,  1XYZ,  2XYZ).  Use  the  temporary  number  for  entity  type  or  form 
numbers  (see  section  3.2.1),  prefixing  it  with  an  alphabetic  character  (e.g., 
A1XYZ)  if  necessary  due  to  multiple  types/forms.).  Edit  masters  as  required, 
and  print  a copy.  Save  to  floppy.  IPO  computers  do  not  include  a CAD  system, 
so  unless  you  have  brought  software  with  you,  illustrations  must  be  omitted  or 
hand-drawn  and  prepared  as  IGES  files  after  the  meeting  but  before  the  ballot 
printing  deadline. 

3.  Project  Review 

Deliver  printed  copy  to  IGES  Editorial  Committee.  Request  expedited  review. 

If  possible,  a meeting  time  for  review  will  be  scheduled  on-the-spot.  Use  IPO 
computer  again  to  make  corrections  as  required. 

4.  TC  Process 

RFC  author  must  attend  meeting  of  the  obvious  custodian  Technical  Commit- 
tee to  discuss  the  RFC.  If  committee  support  was  identified  as  recommended 
in  step  1,  the  RFC  should  be  ready  to  go  “as  is”  or  with  minor  amendment.  If 
committee  votes  against  the  RFC,  expediting  has  failed;  RFC  author  must 
withdraw  it  or  resume  normal  processing  at  step  2 (see  Section  8.1).  If  the 
committee  votes  for  the  RFC,  it  receives  Recommended  for  Ballot  status. 

5.  Project  Review 

Technical  Committee  Chairperson  attends  meeting  of  the  IGES  Project  Com- 
mittee. The  author  may  attend,  and  is  encouraged  to  do  so.  Chairperson 
requests  expedited  RFC  processing.  The  IGES  Change  Control  Secretary 
assigns  a permanent  RFC  tracking  number  immediately.  If  request  for  expe- 
diting is  approved,  the  IGES  Project  Committee  performs  oversight  review 
immediately.  If  RFC  meets  “ballot-ready”  requirements,  the  RFC  receives 
Approved  for  Ballot  status;  this  status  may  be  conditional  upon  completion 
of  minor  editorial  corrections  or  upon  delivery  of  IGES  files  for  illustrations  to 
the  IGES  Ballot  Coordinator.  If  major  problems  are  found,  or  if  request  for 
expediting  is  denied,  expediting  has  failed;  RFC  receives  Open  status  and 
returns  to  normal  processing  at  step  7 (see  Section  8.1). 

6.  Final  steps 

Expediting  has  succeeded;  RFC  returns  to  normal  processing  at  Step  9 (see 
Section  8.1).  After  ballot  results  are  received,  author  must  make  a special 
effort  to  resolve  all  comments  before  the  next  IPO  meeting  (see  step  10,  Sec- 
tion 8.1)  to  prevent  comment  resolution  delays  from  preventing  the  RFC  from 
getting  into  the  desired  version  of  the  Specification. 
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9.0  Editing,  Managing,  and  Publishing  the  Specification 

The  IGES  Editor  and  IGES  Editorial  Committee,  along  with  Technical  Committees  and  RFC 
authors  proposing  changes,  jointly  share  the  responsibility  for  producing  the  Specification  in  a 
high-quality  manner.  It  should  be  written  succinctly,  grammatically  correct,  organized  in  an  easy- 
to-use  manner,  consistent  in  style,  and  accurately  managed  to  avoid  introducing  errors. 

The  IGES  Editor  is  responsible  for  ensuring  that  Editorial  Committee  members  are  qualified  to 
perform  the  editorial  review  required  to  attain  these  goals. 


9.1  Editorial  Review 

Neither  the  IGES  Editor  nor  the  Editorial  Committee  members  are  responsible  for  preparing 
RFCs.  If  either  chooses  to  make  an  exception  and  help  someone  out,  this  shall  not  be  interpreted 
as  setting  a precedent  for  future  agreement  to  do  so. 

All  RFCs  must  undergo  “editorial  review”  during  their  preparation  process.  Any  member  of  the 
IGES  Editorial  Committee  may  perform  the  review.  If  the  RFC  author  disagrees  with  any  Edito- 
rial Committee  member’s  review,  the  author  may  request  a secondary  review  by  the  IGES  Editor. 
If  the  secondary  review  still  is  unsatisfactory,  the  RFC  author  may  appeal  to  the  IGES  Project 
Committee  (see  Section  5). 

In  some  instances,  the  amendment  of  the  RFC  during  consideration  by  the  custodian  Technical 
Committee,  the  IGES  Project  Committee,  and  by  the  IGES  Ballot  Group  may  require  repeated 
editorial  reviews  until  the  RFC  reaches  ECO  status. 

Editorial  review  results  in  marking  up  the  paper  copy  of  the  RFC  by  the  reviewer.  The  RFC  author 
(or  if  unavailable,  the  Chairperson  of  the  custodian  Technical  Committee)  is  responsible  for  mak- 
ing the  exact  corrections  marked  to  the  electronic  form  of  the  RFC.  If  inexact  corrections  are 
made,  the  IGES  Editor  reserves  the  right  to  correct  them  during  the  document  update  process  or  to 
return  the  ECO  to  the  IGES  Project  Committee  for  reconsideration. 

The  IPO  shall  provide  funding  as  necessary  for  reasonable  expenses  incurred  by  the  IGES  Editor 
for  editing  and  producing  of  the  Specification. 

9.2  Managing  the  document 

The  IGES  Editor  is  a volunteer  position;  therefore,  it  is  likely  that  his  employer’s  computer 
resources  will  be  used  for  managing  the  configuration  of  the  Specification  document.  Accord- 
ingly, the  Editor  may  choose  any  workable  methods  to  accomplish  this  task  which  are  available 
and  suitable. 

Ordinary  care  shall  be  exercised  in  the  security  of  the  data,  and  at  least  two  off-site  back-up  copies 
of  relevant  data  shall  be  retained  in  different  locations.  Data  to  be  retained  includes:  the  master 
files  for  the  Specification,  the  designated  document  processor  software,  and  the  designated  IGES 
post-processor  software.  Regular  on-site  backups  should  be  performed. 

The  input  used  to  update  the  Specification  (i.e.,  the  integrated  electronic  form  RFC)  shall  be 
retained  permanently  on  magnetic  media  or  until  such  time  as  further  changes  to  the  Specification 
are  no  longer  made. 
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9.3  Publishing  the  document 

The  IGES  Editor  shall  prepare  camera-ready  output  of  the  Specification  when  directed  to  do  so  by 
the  IGES  Project  Committee  in  response  to  its  assignment  of  Approval  for  Ballot  of  a tracking 
RFC  to  approve  a new  version  of  the  Specification,  and  at  other  times  as  necessary,  such  as 
submission  of  the  Specification  to  ANSI  as  a proposed  national  standard. 

Publishing  of  the  Specification  is  the  joint  responsibility  of  US  Pro  and  NIST.  Any  agency  distrib- 
uting copies  of  the  Initial  Graphics  Exchange  Specification  is  hereby  directed  by  the  IGES  Project 
Committee  to  include  the  applicable  IGES  Recommended  Practices  Guide  with  all  copies  of  the 
Specification  either  sold  or  given  away  since  any  Specification  user  should  have  access  to  both 
documents;  the  Guide  may  be  distributed  separately,  but  not  the  Specification. 


41 


Operating  Procedures  and  Life  Cycle  for  IGES 


Appendix  A 

A rtivity  Model:  Changing  IGES 

The  following  model  is  ne  IDEFO  language.  The  reference  for  this  language  is  FIPS  1 83.  This 
FIPS  may  be  accessed  through  Internet  World  Wide  Web  (http://nemo.ncsl.nist.gov/idef);  a copy 
of  this  standard  may  be  obtained  by  request  for  FIPSPUB183  to 

NTIS 

U.S.  Department  of  Commerce 
Springfield,  VA  22161 


Model  Sheets: 

A-0;  The  Procedures  for  Changing  IGES 

A 0;  Make  Repair  or  Extension  to  the  Specification 
A 0 Text;  Description  of  Activities 
A 2;  Draft  an  RFC 
A 2 Text;  Description  of  Activities 
A 24;  Create  LATEX  RFC 
A 24  Text;  Description  of  Activities 
A 4;  Ballot  the  RFC 
A 4 Text;  Description  of  Activities 
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